|
Boost : |
Subject: Re: [boost] [msm] nested pseudo exits with same event ending up in no trans in the most outer state machine.
From: Richard Szabo (sz.richard_at_[hidden])
Date: 2010-07-19 13:34:14
Hi Christophe
humm......
but In our design We actually do thinks in the constructor of the back end.
and We use multiple inheritance as well where derived is inherited
from msm:backend and some other base classes to couple MSM with our
existing message dispatching FW and call process_event.
Is it not allowed to use derived classes as backends ?.
I was not a ware of it. Is it mentioned in the documentation ?
It gives me a lot headache to change our design now ... :(. we have
spent now about 2 man month altogether to implement base classes
around msm now if this is a case I have to change all of it.
is there a way to allow such a implementation ?.
Br.
Richie
On 19 July 2010 11:28, Christophe Henry
<christophe.j.henry_at_[hidden]> wrote:
>>Hi All
>>
>>I have run in to the following problem :
>>if I have 3 state machines where 1st has a composite state which has
>>one more composite state than the most inner one enters to a pseudo
>>exit state which sends finish event.
>>The middle one has a transaction from the most inner pseudo exit with
>>even finish to a pseudo exit middle state which sends finish again.
>>The most outer state machine has a transition from the middle pseudo
>>exit with event finish to a internal state.
>>when the most inner pseudo state sends event finish it ends in a NO
>>transition on the most outer state machine instead of triggering the
>>transition in the middle state machine.
> <snip>
>
> Hi Richard,
>
> Remove these lines:
>
> //struct test1 : msm::back::state_machine< test1Sm >
> //{
> //};
> //typedef test1 Test1Player;
>
> And replace them with:
>
> typedef msm::back::state_machine< test1Sm > Test1Player;
>
> And it should work.
>
> Regards,
> Christophe
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk