summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorGravatar Tomaz Canabrava <tcanabrava@kde.org>2014-02-06 15:38:32 -0200
committerGravatar Dirk Hohndel <dirk@hohndel.org>2014-02-06 11:32:44 -0800
commit677e75fbe4be9d0d283be5859409a1f4f75e4444 (patch)
tree090d1384ae06b9f2ea8b64fc869b848a38438c73 /Documentation
parent49f8456ce8772e1a4a0cc3eed5786db13ff0ece7 (diff)
downloadsubsurface-677e75fbe4be9d0d283be5859409a1f4f75e4444.tar.gz
Process events just after starting the StateMachine
This is needed because of a braindead issue on the Qt event loop: http://stackoverflow.com/questions/10059721/qt-qstatemachine-sync-problems-initial-state-not-set-on-started-signali For the "event 1" to be received, the machine must already be in a state that react to that signal. Even it was a queued connection, the slot would be queued but only after the signal was received, which it isn't since there is no connection yet at that point. To solve your problem, you can wait for the machine is in "state A" before emitting the signal: machine->start(); qApp->processEvents(); Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Diffstat (limited to 'Documentation')
0 files changed, 0 insertions, 0 deletions