RE: [Boost-users] Weird behaviour when changing states in boost::fsm
Hi Jan,
-----Original Message----- [mailto:boost-users-bounces@lists.boost.org] 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. ##########################################################################
participants (1)
-
Darryl Green