Hi Andreas, Don't have a solution yet, although I understand the problem you describe about the guard conditions over a completion transition. If I come up with an elegant solution I will post it in this newsgroup. I have yet another question regarding events: Can you create a hierarchy of events in such a way that Boost is able to distinguish between the new subtypes? Here is an example to clarify the question: class AbstractEvent : public sc::event<AbstractEvent>{}; class EventA : public AbstractEvent{}; class EventB : public AbstractEvent{}; In this example, events EventA and EventB have the same type ID as AbstractEvent in Boost. Is there a way of giving EventA and EventB different type IDs, without inheriting directly from event< ... >? Thank you, Francisco Santos Andreas Huber wrote:
Hi Francisco
Are completion transitions and events supported by the Statechart Boost library?
No, they are not currently supported. You are the first to ask for them.
I did consider to add them but was unable to come up with a clean implementation, see below.
A completion transition is a transition without an explicit trigger, although it may have a guard defined.
IIRC, this was the main obstacle. If, when the first completion event is generated, the guard is false, what does then happen? Will there be another dispatch of such an event? If so, when or under what conditions?
When all transition and entry actions and activities in the currently active state are completed, a completion event instance is generated. This event is the implicit trigger for a completion transition. The completion event is dispatched before any other queued events and has no associated parameters. For instance, a completion transition emanating from a concurrent composite state will be taken automatically as soon as all the concurrent regions have reached their final state. If multiple completion transitions are defined for a state, then they should have mutually exclusive guard conditions.
Maybe you have better insight into how this should work?
Regards,
-- Andreas Huber
When replying by private email, please remove the words spam and trap from the address shown in the header.