Hi Mandeep and K.Frank!
...
>> Let's take a over-simplified SM.
>>
>> A->B->C->D
>>
>> now if the app crashed while it was state C, on restarting the app, I don't
>> see a legal way of directly taking the SM to C, other than replaying the
>> events that caused transitions to it.
>>
>> Or is there some other trick to it?
>
> First, I won't speak to the details of the Qt state-machine
> implementation (because I don't really know them).
Ok, sure we can implement it on our own but still the question is if QSM
can assist here. But lets keep it general for now.
> I wouldn't call it a trick.
> It's reasonable to imagine that your state-machine framework
> can do something (or can be modified to do something) like
> this:
>
> myStateMachine.state = stateC;
In general such a call would be against any finite state machine
structure, right? For safety I would set this method as a very rare used
friend method in order to prevent misuse.
> So, schematically, your code might look something like this:
>
> if (normalMode) {
> startEventLoop();
> }
> else if (recoveryMode) {
> myStateMachine.state = stateC;
> startEventLoop();
> }
>
> If your state-machine framework won't let you do this, or if you
> prefer to live within the formal approach of events and transitions,
> then you could add some helper events and transitions to your
> state machine. Let's say that your state machine gets initialized
> to startState. Then you could add:
>
> event transition
>
> goToA: startState --> stateA
> goToB: startState --> stateB
> goToC: startState --> stateC
> goToD: startState --> stateD
>
> Then at startup, if you're in recovery mode, you would do
> something like;
>
> myStateMachine.postEvent (goToC);
>
> (But I would probably consider this overkill, and just
> implement making "myStateMachine.state = stateC;"
> work.)
Well, in general I would consider working with this approach and
automatically adding those transitions between the start state and all
other states. QTransition could be derived to QRecoveryTransition that
throws only if a QRecoveryEvent is posted.
But then we would need to keep some kind of a reference to the current
state within the state machine. And I saw no opportunity to address the
current state in QSM. Automatically adding a unique ID might help here...
But as my intention is to use this approach in a work flow driven
application that takes care of building up a set of data I also will
have to take care of keeping data and state machine consistent.
If some data would be lost but the state machine is recovered to a later
state then we would end up in an inconsistent state! So recovering any
state without check of data is critical.
So my current approach is to recover the data and set up a special
QRecoveryState/-Transition connection with guards on data elements that
once an QRecoveryEvent is posted automatically goes all the way to the
right state.
Would that be a considerable approach?
Great discussion!
Best Regards,
Ingmar
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
