Hi Robert
I was thinking of using Boost.Statechart as a state machine to manage widget states in my wxWidgets application. Depending on what menu options the user picks in my program, certain buttons on the main window will be enabled or disabled. I figured this would be a good opportunity to use Boost's state machine system. I would create states that would enable or disable certain buttons depending on what events I publish. For example, when the user chooses the "Edit Name" menu item, then buttons for editing a name would be enabled. This means I'd publish a EditNameEnabled event, or something, and then the EditNameMode state would become active, and its constructor would enable certain buttons.
Transition actions might be a better place for such logic, see below.
Of course, this means I'll need to be able to pass construction parameters to certain fsm state objects, and in the Statechart tutorial they only use default constructors. I'm not sure how I'd pass button object pointers to these state classes so they can work with them. I have two questions:
First, does Boost.Statechart seem like the right tool for this job?
Frankly, I'm not sure. In my experience, GUIs tend to have static behavior. That is, pressing a given on-screen button in different states of the application usually leads to the same action being executed. You *can* implement such behavior with an FSM, but I think that would increase complexity unnecessarily (compared to the straight-forward implementation with simple callbacks). IMHO, FSMs really shine when you need to implement context-dependent behavior, i.e. the same event can trigger different actions depending on the current state (which is e.g. often the case for devices with hardware buttons). Then again, I know engineers who swear by using FSMs to implement normal GUIs.
If yes, then how can I pass parameters to state object constructors?
IIUC, then you'd want to pass GUI object pointers to state constructors, which would then disable/enable/whatever those objects, right? If so, then I think that is not the best way. On a logical level, the FSM would be relatively tightly coupled with the GUI elements anyway, so I'd simply pass a window/dialog pointer to the state machine ctor, which would store it in a data member. Actions in the FSM would then first get the window from the FSM and then enable/disable controls of the window as needed. If you want to/must pass widget pointers then I'd implement the enabling/disabling logic in transition actions. Unlike entry- & exit-actions, transition actions can access the triggering event, which would of course carry the affected widget pointers. HTH, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.