Boost logo

Boost Users :

Subject: Re: [Boost-users] [statechart] Passing parameters to state objects
From: Andreas Huber (ahd6974-spamboostorgtrap_at_[hidden])
Date: 2009-09-29 15:19:06


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. 

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