Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!mcnc!ece-csc!ncrcae!ncrlnk!uunet!mcvax!cernvax!ethz!forty2!poole
From: poole@forty2.UUCP (Simon Poole)
Newsgroups: comp.sys.atari.st
Subject: Re: button events.  Wanting to wait for either one or two clicks.
Keywords: evnt_button, evnt_multi, Laser C
Message-ID: <528@forty2.UUCP>
Date: 26 Nov 88 16:35:56 GMT
References: <1988Nov19.180454.563@gpu.utcs.toronto.edu> <7632@pasteur.Berkeley.EDU> <6982@chinet.chi.il.us>
Reply-To: poole@forty2.UUCP (Simon Poole)
Organization: Exp. Physics University Zuerich
Lines: 23

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/...
calls, things can become dreadfully  unsynchronized (this is one thing
to  look  out for, if you use  the solution that was  suggested to the
original question (installing a mouse interrupt  handler that maps all
buttons to  the  left one (something I  did  for UniTerm  a  long time
ago))).

-- 
----------------------------------------------------------------------------
UUCP:   ...mcvax!cernvax!forty2!poole			Simon Poole
BITNET: K538915@CZHRZU1A
----------------------------------------------------------------------------