Traitement des évènements d'une QScxmlStateMachine
-
Bonjour,
J'utilise avec bonheur QScxmlStateMachine depuis deux ou trois semaine.
Une première machine d'états suit l'état d'une base de données, et tout fonctionne bien.
Une seconde machine d'états fonctionne moins bien et j'aimerais vos lumières.Lorsque je déclenche un changement d'états avec submitEvent, je constate que le changement effectif d'état n'a pas lieu de suite, mais juste avant que l'application redonne la main à l'utilisateur. Or entre le submitEvent et l'attente d'une action utilisateur je réalise des opérations qui dépendent de l'état actif.
J'ai l'impression que la boucle des évènements ne traite ceux de la machine d'états qu'en dernier.
Alors j'ai cherché en vainc dans l'API de QScxmlStateMachine comment "purger" la file des évènements juste après le submitEvent.Quelqu'un sait ce qu'il faut faire ?
Sylvain -
Bonjour,
Solution trouvée : appeler
QApplication::processEvents(QEventLoop::ExcludeUserInputEvents);
juste après un
submitEvent();Cette solution n'est pas préconisée par la doc Qt. J'ai donc essayé de récupérer un handle vers la QEventLoop de l'application mais je ne trouve pas comment faire...
-
qApp->processEvents(QEventLoop::ExcludeUserInputEvents)
C'est une macro qui return l'object Q(Core,Gui)Application.
processEvents
est de toute façon une méthode static donc c'est la bonne event loop qui est appelée. Ce qui n'est pas recommandé est l'usage de cette méthode. -
This post is deleted!
-
Depuis le temps j'ai pensé à une autre solution potentielle :
- créer une nouvelle boucle d'évènements dans celle de l'IHM ;
- "raccrocher" les évènements des QScxmlStateMachine à cette nouvelle boucle d'évènements.
Si le premier point est assez simple, je ne sais pas encore comment assurer le second. Ce serait possible ?
-
Serait-il possible d'avoir un démonstrateur minimal qui permette de voir le soucis de cette state machine ?