Hi,
>I see now that it's not that that the sub-machine is a state of the main machine, but ANY time you have an entry action performed
> directly from the machine level the fsm is reported as a state and
not as an fsm.
>This isn't a problem since I know this is happening,
but perhaps it might be possible to change this so fsm entry actions put the
fsm
>in the fsm parameter slot?
I don't think it'd be a good idea. Or I might misunderstand your point.
>What is fsm equal to when an entry action is performed?
FSM is the state machine containing this state / state machine / terminate state etc.
STATE is the state being entered / exited.
This means, if you have a state executing this entry, you can rely on it being in the STATE parameter. If later you replace this state by a submachine (which is also a state, right? ), your "state" is still represented by the STATE parameter. Anything else could be rightfully considered a violation of the liskov substitution principle. Imagine if you had to rewrite all your functors because you move from a state to a submachine...
I'm afraid you're confusing a type, like state_machine with its function in the context of an outer state machine. You're not seeing a TERMINATE_STATE template parameter, right?
>Here's some code that shows exactly what can be set where and when for anyone else who is trying to figure this out...
Let's typeid the parameters:
rootFSM_action: When this executes, the current state is MSM_B, there is no containing FSM
=> STATE is MSM_B. FSM also because we have no outer fsm, but this a corner case. I wouldn't want to pass a dummy fsm.
someAction: When this executes, the current state is MSM_A, containing FSM is MSM_B
=> STATE is MSM_A, FSM is MSM_B because this substate is contained by MSM_B.