🚀 go-pugleaf

In article <528@forty2.UUCP>, poole@forty2.UUCP (Simon Poole) writes:
> In article <6982@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes:
> >I'd like to tag an old question onto this discussion of button sensing: some
> >mouse sensing calls leave the machine in an unexpected state.  In particular,
> >after using a call (was it vq_mouse()?) to interrogate the mouse button state
> >in a loop, an evnt_multi() waiting for a mouse event exits immediately, even
> >if a fairly long time elapses between the completion of the loop and the call
> >to evnt_multi().  Does this sound familiar to anyone?  Would you care to
> >explain the scope of this peculiarity, and suggest a remedy?
> 
> What's unexpected  about this? Doing a vq_mouse  (a VDI call) does not
> effect the AES event queue in  anyway, in particular  it doesn't cause
> events to get lost. In general it's not a good idea to mix AES/VDI/...



One thing that's unexpected is that my understanding of the GEM messaging 
philosophy is that if no program is waiting for a message, it will vanish
invisibly.  It would certainly annoy me if keyboard events I had no interest
in and was not waiting for corrupted the message system, or if someone's
mistaken attempts to use the mouse (in a program segment which used keyboard
entries only) resulted in trouble in a later program segment which did use the
mouse.  I presume your explanation (that mouse events are queued even if they
aren't being waited for) is correct, since you have much more experience than
I have.  I guess clearing an event queue isn't much different from clearing
a type-ahead buffer, so I'll try it.  Thanks.
                                 Steve