""Christian Bähnisch"" <christian-baehnisch@gmx.de> wrote in message news:20070822084753.176280@gmx.net...

I'm working on a controller connected to a external device through a serial port. I have to process events triggered by the device which can be group into several categories like simple status events "My firmware has version XXXX" or "the result of my last working step was XXXX" as you can see my events carry data. I want to encapsulate this communication events in statechart events, so I can change to states depending on the event's category, and then make further processing where I have to extract data I have passed into them.

Ok.

I thought this would be a common use case for a statechart appproach ...

Yes, it is and in the generality you've described the problem it is fully implementable with the current version of the library. Pretty much all the FSM frameworks I've used support this use case with _transition_actions_. That is, you define a function that is called whenever the transition is triggered by an event. When the event is processed, the triggering event is passed as an argument to said function. Boost.Statechart is no different here, please see: <http://www.boost.org/libs/statechart/doc/tutorial.html#TransitionActions> Now, you seemed to say that you regularly want to access the triggering event in _entry_ and _exit_ actions. In my experience this is rarely necessary and is problematic because there's no way to enforce type safety at compile time. That's why I asked you to provide an example. Your use case doesn't seem to require such access to the triggering event. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.