I ended up implementing timeout support with a WM_TIMER handler in the parent of the state machine class. ...
Does the WM_TIMER handler really add the event to the queue of the state_machine subclass object? If so, then you might have introduced a race condition. WM_TIMER handlers are called in a dedicated thread, right?
From my understanding of the documentation of SetTimer and my use of it, everything should be working from the same thread (WM_TIMER messages are posted to the main thread's message queue, where they are processed while the thread is idle). So, I don't think there's a race condition.
Ahh yes, good old WM_TIMER... You are of course safe as long as only the main thread calls state_machine::process_event().
and awkward instancing of the event.
I don't understand. You mean the special constructor you have to add to the state, right?
Well, that, but more importantly, the cast inside of the post_event. Making calls to post_event from a constructor/enter seem like a fairly typical use case.
Hmmm, with "cast" you mean the call to the context<> function? Have you noticed that there's a simple_state::post_event function, ... http://www.boost.org/libs/statechart/doc/reference.html#post_event1 ... which you are allowed to call from a ctor of a state subclass? HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.