On Thursday 07 August 2008 10:58:21 am Andrey Semashev wrote:
I see. However, tags are not a good candidate to dispatch events on since different events can have same tags. I think, the event itself should contain enough information to be dispatched after being postponed.
BTW, you can achieve the same functionality right now if you bind the event to the process function of the FSM and save the call into boost::function.
I never thought of that one. Maybe a little mention in the Documentation would be good. I imagine other potential users might want to do the same.
I think, this would be an interesting feature to add in future releases. I won't be able to implement it before the review. State and transition base classes will have to be extended, in order to allow to postpone events. State machine and event classes will have to be modified too.
Yeah, something like EventID and TransactionID in each event and transaction would be nice along with I imagine a deferred_state_machine and a deferred_lock_state_machine Thanks, Chris