Re: Consequences of the final state?

I understand and fully agree. If we don't want to process event in the
ancestors states after the final state is reached, we just have to
traverse out by the done.state.id event.

While this is great for compound states, I like to point out, it's
less great for parallel states. Suppose we have A and B in parallel,
and want to stop event processing in A if A reaches the final state.
We would have to wrap A in a compound state to catch the done.state.id
and move to a "waiting state" which would be inside the parallel state
but outside A.
Otherwise B would be left also, which is not wanted in this scenario.

Is that correct, or do I miss something?

On 2 June 2014 15:41, Jim Barnett <1jhbarnett@gmail.com> wrote:
> There is nothing special about event processing in final states (except for
> a top level one).  When we are in a final state (except for the top level
> one) events are processed normally.  The final state cannot contain any
> transitions, of course, but transitions in ancestor states will be
> considered.
>
> If the state machine swallowed events when it was in a final state, it would
> get stuck there forever.  We want that behavior when we reach a top-level
> final state (i.e. a child of scxml), but not  when we are in the final child
> of a compound state.  The main effect of a final child of a compound state
> is to generate a 'done' event indicating that the compound state has, in
> some sense, finished its processing.  This is primarily useful in complex
> state machines where complex compound states act as a form of subroutine.
>
> On 6/1/2014 10:00 AM, c64zottel . wrote:
>>
>> Hello,
>>
>> maybe I over read it, but nowhere seems an information, what happens
>> to events in a compound state, when it had already reached the final
>> state?
>>
>> <state id="a">
>>    <state id="s">
>>      <transition event="d" target="f"/>
>>    </state>
>>    <final id="f"/>
>>    <transition event="e" target="x"/>
>> </state>
>> <state id="x"/>
>>
>> Lets say, we entered s, so our configuration looks like: { a, s, scxml
>> }, now e occurs, where s doesn't provide a transition, but a does, we
>> would end up in { x, scxml }
>>
>> My question is now, what is, if we are in f: { a, f, scxml } an e
>> occurs? is the event swallowed or passed up to a? That would kind of
>> defeat the purpose of final, or?
>>
>
> --
> Jim Barnett
> Genesys
>

Received on Monday, 2 June 2014 18:32:34 UTC