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
IWegner iweg...@gmx.de schrieb:
Hi mandeep,
thank you for your quick comments and suggestions.
I was also thinking of sub states for tasks as each task will have its own logic. It will be activated by the overall application state machine.
Great to hear, that this is
Hi Mandeep (and Ingmar)!
On Fri, Oct 11, 2013 at 12:37 PM, Mandeep Sandhu wrote:
Adding Ingmar to the loop... :-)
On Oct 11, 2013 6:59 PM, K. Frank wrote:
Hello Mandeep and Ingmar!
On Fri, Oct 11, 2013 at 1:04 AM, Mandeep Sandhu
wrote:
...
I don't think QSM provides this feature. The
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
Hi Ingmar!
On Fri, Oct 11, 2013 at 3:51 PM, Wegner wrote:
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
On Fri, Oct 11, 2013 at 12:05 AM, Ingmar Wegner iweg...@gmx.de wrote:
Hi list,
we are planning of using QStateMachine (excellent work, guys!) for a
workflow driven application (tasks).
I am thinking of an architecture in which tasks have their own state
machine (QState) that will be
