Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!agate!stew.ssl.berkeley.edu!ericco
From: ericco@stew.ssl.berkeley.edu (Eric C. Olson)
Newsgroups: comp.sys.atari.st
Subject: Re: Event multi
Keywords: ST
Message-ID: <1989Oct17.052250.29145@agate.berkeley.edu>
Date: 17 Oct 89 05:22:50 GMT
References: <1989Oct14.091054.12986@agate.berkeley.edu> <2935@jhunix.HCF.JHU.EDU> <1329@gmdzi.UUCP> <1989Oct15.223739.9084@chx400.switch.ch>
Sender: usenet@agate.berkeley.edu (USENET Administrator;;;;ZU44)
Organization: University of California, Berkeley
Lines: 26

In article <1989Oct15.223739.9084@chx400.switch.ch> poole@chx400.switch.ch (Simon Poole) writes:
>[Sigh! This one turns up often enough to be included on a list of
>commonly asked questions, did anybody ever do something about this?]
>
>Your best bet is to install your own vdi mouse button handler, save
>the "incoming" button mask in a variable and replace the original value
>(if I remember correctly it's in d0) with the value for the left button.
>After you've done that jump to the original button handler, the whole
>thing needs just a couple of assembler instructions, so it's really
>trivial. In your event loop just wait for a left button event and then
>sample the stored value for the button that was really pressed.

I can always hack around the operating system.  I find that I almost
always have to hack around GEM for any non-trivial program.  But I'm truly
amazed that GEM can't even handle selecting the left button OR the right
button.

Because of this I'm always tempted to circumvent GEM completely.  Which
defeats the purpose of having something like GEM.

Enough said,
Eric


Eric
ericco@ssl.berkeley.edu