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

[Mandeep Sandhu]

Oops, i forgot to mention the article:

http://doc.qt.nokia.com/qq/qq11-events.html

(See "The Origins of Events " section).

-mandeep


On Wed, Jun 22, 2011 at 6:21 PM, Mandeep Sandhu
<mandeepsandhu.chd at gmail.com> wrote:
> 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
>