[Qt-interest] Qt state machine: problem while queuing multiple events

[Mandeep Sandhu]

Hi All,

I was experiencing a problem in my state machine and wanted to
understand how/when events posted to other event loops processed.

I'll illustrate the issue with a simple statemachine.

S1 --e2-- >  S2 -- e3 --> S3
/\                   /\                   |
 |__back___|__back___|

(dia best viewed with fixed-width font!:)

Most of the transitions are pretty simple. I'll explain the 'back'
event transition a little more.

In S3, if I receive e3 I post a 'back' event to the state machine
which takes me to S2. Similarly, generate a 'back' event, if I receive
e2 while in S2. This check is done right before I'm about to post the
event. That is I determine, based on the current state of the SM,
whether to post the event as-is or to translate it to 'back'.

Assume that e2 and e3 are tied to keyboard keys 2 and 3.

Now the SM works fine if I press keys 'slowly' :) I.e I press 2, then
3, then keep pressing 3 it toggles between S2 and S3.

However, pressing key 3 quickly can result in the SM landing in S1,
even though only 3 key is being pressed.

This happens because, when in S3, my keyboard events are coming
rapidly and I receive 3 more than once even before I make a
transition. So because of the translation I end up queuing TWO back
events in the SM's event queue. And not surprisingly, end up in S1 (S2
-back-> S1).

I was initially under the impression that once I've posted my events
to the SM event queue, any subsequent key-press event will be
processed after the SM event is processed. But thats not correct as
this old Qt article explains:


There a couple os solutions to prevent this from happening...but they
all look a little hacky to me:

1. Enqueue only a single event to the SM. QSM itself provides no way
to do that. So I'll have to manage my own queue outside of it. In this
solution I have to rely on knowing when an event has been
consumed/rejected by the SM.
2. Disable key handling after posting an event. This would however
require me to know which events are valid and which one's aren't
(again I'll have to rely on some way of knowing whether the event was
accepted/rejected).

In both cases, this means using some undocumented (public) QSM API's
like overloading endMicrostep() etc.

Is there any other way to handle this issue?

Thanks,
-mandeep