Path: utzoo!attcan!uunet!mcsun!unido!opal!tmpmbx!netmbx!askrid From: askrid@netmbx.UUCP (Dirk Ahrens) Newsgroups: comp.sys.atari.st.tech Subject: Re: Reading both buttons from Eventmulti Message-ID: <1355@netmbx.UUCP> Date: 5 Nov 90 17:40:39 GMT References: <9479@jarthur.Claremont.EDU> <3209@medusa.informatik.uni-erlangen.de> <10330@ubc-cs.UUCP> Reply-To: askrid@netmbx.UUCP (Dirk Ahrens) Distribution: comp.sys.atari.st.tech Organization: netmbx, Berlin, West Germany Lines: 34 In article <10330@ubc-cs.UUCP> horsch@cs.ubc.ca (Michael Horsch) writes: >In article <3209@medusa.informatik.uni-erlangen.de> >>csbrod@medusa.informatik.uni-erlangen.de (Claus Brod ) writes: >>One method - undocumented though, but valid for all TOS/GEM versions - >>is to add 256 to the number of clicks waited for. This negates the condition >>for a return from evnt_multi due to clicks. Example: >>This means: Wait for 'NOT both buttons released' = 'One button clicked'. > >So what's wrong with alternating the value of mbuttons in the >loop containing event_multi()? On each pass through the loop, >check for only one button, and at the end of the loop change the >value of mbuttons to the other mouse button (ex-or mbuttons with >3). Easy. >Michael C. Horsch Dept. of Computer Science, >horsch@cs.ubc.ca University of British Columbia The problem is, you got to have an event_timer in your loop otherwise you will never be able to change the values. If there is no timed event, why should you specify it, and the gem-dispatcher is doing more, than he must do. Since this 'feature' exists since tos 1.0, it needs a simple "we will keep it" from Atari to avoid 'workarounds' like yours. If, on the other side, atari sais "this is subject of change" we have to use this, or any other solution. But I doubt, there is any solution, that is as elegant as the above. Greetings Dirk -- Askrid netmbx, Jabba the Hutt. askrid@netmbx.UUCP dirk@opal.cs.tu-berlin.de AHRENS@TUBVM.CS.TU-BERLIN.DE Dirk Ahrens - Danckelmannstr 46 - 1000 Berlin 19 - Federal Republic of Germs