Boost logo

Boost Users :

From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2007-03-28 14:43:55


Federico J. Fernández wrote:
> I'm using statechart for a project and I'm trying to do the following
> without success.
>
> I want to get a new event for the statechart when an event is
> processed. I mean, call process_event with an event and get another
> event as a result.

Ok, what will happen with this event? Should it be processed by the same
state machine object or a different one? I guess a different one,
correct? (If its the same FSM object then you should call post_event
from an action).

> We tried with different approaches. For example,
> modifying the passed event (but it's const) and trying to do a custom
> reaction that returns something (but I had problems too.. don't
> remember exactly now).

The easiest way to get back a result from a state_machine is to add a
boost::function object as a member of the event:

1. Add either an in_state_reaction or a transition with a transition
action to your state_machine. The triggering event should contain a
boost::function object as member. The action should call this object.
2. Construct the event and set the boost::function member to a suitable
callback function. In your case that function would accept an event
parameter.
3. Call process_event, passing the event object.
4. Your callback function is called.

This is the easiest way to do it but also the most dangerous, please see
"Why asynchronous state machines are necessary":

http://www.boost-consulting.com/boost/libs/statechart/doc/tutorial.html#AsynchronousStateMachines

IOW, you might want to use an asynchronous state machine instead of your
synchronous one.

> and the question is... Is there a better way to do this?

Yes, see above. Hope that makes sense...

Regards,

-- 
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header. 

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net