I tried and it worked. I did: - declare pseudo exit: struct payment_done: public exit_pseudo_state<none> - change inside transition: Row < check_payment, none, payment_done, none, is_paid> - changed outside transition: Row < Payment::exit_pt
, none, waiting, dispense_item, none> And it compiles and does the work (from what I understood of your program). I tried with the newest version. If you still have a problem, it might be an old bug. What version are you using?
--> I got it working too. I was defining the payment_done state as struct payment_done: public exit_pseudo_state<>, instead of struct payment_done: public exit_pseudo_state<none>. I corrected it and now the code is compiling without error.
Ok, good.
An elegant way to do this is to add this info in the event. Like this you can save it in Payment (you get the event in on_entry and the target state is also passed to the transition). I like to see this as the UML equivalent of a function call.
--> As per my understanding, it will be possible to convey the info through an event only if two states are "connected" by an event. But if one has to access info in one state from another state and if they are not connected by an event as such, what will be the best way to do that? (In the vending machine example, the product gets selected in the "selection" state and gets dispensed in the dispense_item action. These two are not directly connected through an event.) I can think of one way (not sure if its the best way to do that though) where the state machine itself stores pointers to objects that represent states. (eg: state machine have a pointer struct selection *sel_ptr; The selection state on entry will then update this variable with "this" ptr. i.e the on_entry method of selection state will have a statement: sel_prt = this;). This won't however work if a submachine has to access info stored in the parent machine.
Thanks!
In your case, I think it'd make sense to pass it in the event going from
selection to Payment because the choice is the result of selection, right?
Then Payment could store it (or a reference/pointer to it) in its on_entry.
A second possibility (but IMO less clean) solution would be to add an action
in the transition selection - key_press - Payment. This action would set the
info into the target state (Payment). Then your submachine works with
correct data.
The third possibility (we're getting less and less clean here) is for
on_entry of Payment to access the info from its parent state machine (the
FSM parameter, as Payment is a substate of your vending_machine).
And finally, the method to use when nothing else works, get vending_machine
or selection set the data directly inside Payment (using
get_state