RE: [Boost-users] Weird behaviour when changing states in boost::fsm

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2005-03-01 22:32:54

Hi Jan,

> -----Original Message-----
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Jan Eickmann
> Subject: [Boost-users] Weird behaviour when changing states 
> in boost::fsm
> 
> I have a parent state which has two substates. One is basicly 
> a noop as 
> InnerInitial, the other is and OptionsDialog.
> Now, in a custom_reaction's react function in the parent 
> state, I call 
> transit<OptionsDialog> in order to go to the OptionsDialog-substate.
> What happens is that the parentstate itself is destroyed and 
> reentered, 
> then it enters the OptionsDialog state.
> Something similar happens when I use transit<ParentState> to 
> go back to 
> the ParentState (which should automatically enter the InnerInitial, 
> no?). It exits the OptionsDialog, then exits ParentState and reenters 
> ParentState (I haven't checked if it enters the InnerInitial).
> If in the OptionsDialog, I do a transit<NoOpInnerInitial> it 
> just goes 
> there without first destroying the parent-state (just exits 
> OptionsDialog but not ParentState).
> 
> Is this the expected behaviour, if so, could someone explain 
> how to get 
> the desired behaviour?

Yes it is expected. See transit() in reference. In summary, calling
transit will always exit the current state, and keep exiting back to the
icos of the current state and the final state, then work in again from
there to reach the destination state. Note tht exit = destruct, enter =
construct.

There isn't enough information to properly answer your question. For a
start I don't properly understand your fsm, or whether this is just a
minimal example to illustrate your problem. The obvious answer is  that
you should just make the inner states react to the event you currently
have the parent reacting to. Using the form of custom reaction that
allows a transition context and member function to be specified, you can
make the transition context the parent state and a member function of
the parent can perform action. Of course, if your reason for using a
custom reaction is to implement some form of guard, this won't entirely
solve the problem. The other way to look at this is to see if you can
replace the guard with more states/events (the reaction to the original
event conditionally produces the appropriate more specific event to
cause the correct action and final state).

hth
Darryl.

##########################################################################
This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and 
then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission.  
We have taken precautions to minimise the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any 
attachment to this message.  We cannot accept liability for any loss or 
damage caused by software viruses.

##########################################################################