[Boost-users] Re: boost::fsm, parameters to DestinationState

From: Jan Eickmann (je_at_[hidden])
Date: 2005-03-11 09:13:11

Andreas Huber wrote:
> Jan Eickmann <je <at> framesys.de> writes:
> 
>>I'll try to give some more information. In the application we are 
>>developing, we have a screen that is kind of like an encyclopedia. This 
>>screen is usually shown after the user presses a "more information" 
>>button in a popup dialog, etc.
>>That encyclopedia-screen is the state I want to transit to. Now what I 
>>want to do is tell that screen what entry to show.
>>In order to be able to get back to the original state, I put the 
>>"normal" GUI of the application in a state that has a deep-history.
>>
>>So the common outer state would basicly be the FSM but I would rather 
>>avoid having a variable there as this would require changing the FSM 
>>itself everytime I want to add a similar screen that gets told from the 
>>outside what to do exactly.
> 
> 
> Hmmm, I not sure whether I already have enough information to help but you 
> might consider posting an event containing the necessary information before 
> making the transition. Of course, this does not help you accessing the 
> information from the ctor of the state but the reaction that follows can then 
> access this info, as follows:
> 
> // untested
> struct EvButtonClicked : fsm::event< EvButtonClicked > {};
> 
> struct EvEntryInfo : fsm::event< EvEntryInfo >
> {
>   // Whatever you need to send goes here
> };
> 
> struct Init;
> struct Application : fsm::state_machine< Application, Init > {};
> 
> struct ShowEntry : fsm::simple_state< ShowEntry, Application >
> {
>   fsm::result react( const EvEntryInfo & info )
>   {
>     /* display info here */
>   }
> };
> 
> struct Init : fsm::simple_state< Init, Application,
>   fsm::custom_reaction< EvButtonClicked > >
> {
>   fsm::result react( const EvButtonClicked & )
>   {
>     post_event( boost::intrusive_ptr( new EvEntryInfo() ) );
>     return transit< ShowEntry >();
>   }
> };
> 
> I assume that you have a good reason not to use a GUI framework, which I 
> expect to be better suited to implement the functionality you need than a 
> general FSM framework.
> 
> HTH & Regards,
> 
> Andreas

Thanks for the hint. I think the posting of a second event sounds like a 
good idea.
The reason I'm not using a "normal" GUI framework is that this is 
integrated into a 3D-Engine and the Framework we are using for the GUI 
doesn't have all the features you would expect of something like MFC or GTK.

Greetings,

Rincewind