Darryl Green wrote:
>  Andreas,
> 
>  I have looked more thoroughly at the fsm library and have this
>  specific problem I would like advice on.
> 
>  The source state (as well as all the rest of the active direct and
>  indirect inner states of the innermost common outer state) is
>  destructed before the transition action runs. This means the actin
>  doesn't have access to any of this context, considerably reducing the
>  utility of state local storage. The stopwatch example shows the
>  storage being used in the exit action, which is fine. A more complex
>  example would be likely to have separate actions for multiple
>  transitions. It seems that if actions need access to the state local
>  storage of a state being left one must do the following: 1) Have
>  states with only one transtion. 2) Be prepared to execute the actual
>  "work" done by the system (the actions) in the exit action (which is
>  a destructor).
> 
>  I don't find either of these attractive.
> 
>  Alternatively, a custom reaction can be used. The react function can
>  do processing in the context of the source state (it is a member of
>  the source state). I'm not sure how easy it is to access other active
>  (inner or outer) states at this point?

Hmmm, it is difficult to diagnose your problem without seeing any code or
state charts, so I can only guess here. It seems very unlikely that you
could have missed it but did you miss simple_state::context<> ()? It seems
that this should pretty much solve all your problems?

I assume that you want to access the same variable from entry actions, exit
actions and transition actions. If this is the case then you need to put the
variable in question in an outer context that is shared by all the states
from whose entry or exit actions you want to access it. Moreover, you also
need to ensure that this outer context always exists when any of the
transitions are made, i.e. you may need to push the variable further
outward.
The state_machine<>  subclass itself acts as the outermost context.
Transitions may take place in this context, i.e. *all* states have been left
before the transition action is executed. If so, the variable needs to be
made a member of the state_machine<>  subclass.

You can then access the variable from entry and exit actions with the
context function template. From transition actions you can access the
variable either directly or also through the context function template.
Pitfall: Whenever you need to call context<>  from an entry action, you must
derive the associated state from state<>  instead of simple_state<>.

HTH,

Andreas


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost