Thanks for the responses. > So a base state (child of root, parent of the rest) with a transition would > probably be the best option.
I evaluated this option but it has one unfortunate side-effect. I would need to expose this base state through the API I'm developing and expect the user to make all states children of that base state. The other option would be to hide the constructor of states and only provide them through a factory method, but this sets other unnecessary restrictions. The problem would be solved if QState had an additional method, setParent() to change the parent state after construction similar to QObject::setParent(). Are there technical obstacles for implementing this? I did get around the original problem temporarily by using a mix of signal mappers and ugly signal connection, triggering, and disconnection. - Olli On Wed, Dec 30, 2009 at 2:13 AM, <[email protected]> wrote: > Hi, >>I would expect this to work with the machine itself (which is >>a state) instead of a base state as well. But in my tests it >>doesn't... Maybe checking whether the "root state" is treated >>specially by >>addTransition() or the transition "dispatching" algorithm. > > It wouldn't work from the machine itself, because transitions cause the > source state to exit, and the root state can't exit. > So a base state (child of root, parent of the rest) with a transition would > probably be the best option. > > > Note that all of the algorithm specifcs can be found in > http://www.w3.org/TR/scxml/ - the <scxml> root element can't have a > <transition> child for this exact reason :) > > Cheers > No'am > >> >> >>Cheers, >> >>-- >>Caio Marcelo de Oliveira Filho >>OpenBossa - INdT >>_______________________________________________ >>Qt4-preview-feedback mailing list >>[email protected] >>http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback >> _______________________________________________ Qt4-preview-feedback mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt4-preview-feedback
