Hi Christophe,
1. You mean, that from within the "operator()" of an action I am only allowed to use the parameters for accessing states, events, and the FSM internals? (Neither "event_", "source_", "target_", "fsm_", nor accessing the dummy-instances directly.)
I didn't say this, just the dummy states you declare for the table. If you had this declared:
BOOST_MSM_EUML_METHOD(ActivateEmpty_ , activate_empty , activate_empty_ , void , void )
You could call inside a state action something like:
activate_empty_(target_)(evt,fsm,*this);
or inside an action:
activate_empty_(target_)(evt,fsm,src,target);
But the interest is quite limited. They are made for the transition table. But as you see, msm creates some valid functors.
It seems I was a little unclear with formulating my question. I assumed using "event_", "source_", "target_" and "fsm_" for accessing an attribute from within an action is not allowed. However, there seems to be no real reason for using them in this way, because one could as well use the corresponding action-parameter and its "get_attribute" member-function.
This is now clear for the current event, current source- and target state as well as for all other states of the FSM (by accessing them with "get_state").
2. However, how to access other events than the current one?
It seems to work as I did before (by accessing the "dummy"-instance of the event), but if you do not recommend it, maybe there is a better solution? (I need to access all events directly to initialize their event-number attributes from within the FSM's entry-action.)
Well, you could do this for events. Though as you seem to have a number for every type, a static member could be easier. The normal way is usually in the event constructor but I agree that for eUML, it is not so practical, so yes, your trick will do.
You are right. I would have preferred to use the event's constructor, but on the other side, I also prefer using your macros. :-) But ok, for events that does not seem to be a problem.
3. And all the underscore-accessors "event_", "source_", "target_", "fsm_" are only allowed to be used from within the transition table?
They are allowed everywhere but their main reason of existence is to make a nicer transition table.
And using them for accessing attributes seems to work only reliably in the transition table (at least for states). But that's fine, as one can use "get_attribute" from within actions.
Maybe you could emphasize the real usage in the documentation, so that nobody misuses it (like I did).
Ok, will do. Thanks.
Thank you a lot for all this clarification and especially for this great library. It helps me a lot. Ciao, Deniz