Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!pasteur!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Finding MouseMoved Events
Message-ID: <23826@ucbvax.BERKELEY.EDU>
Date: 30 Apr 88 17:02:54 GMT
References: <8769@eleazar.Dartmouth.EDU> <3068@saturn.ucsc.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Organization: School of Education, UC-Berkeley
Lines: 26

In article <3068@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes:
>described, using GetMouse, you might take a look at the low-memory globals.
>I think that there is a global there that might do some of the work for you.

Of course, if you do this you will instantly be incompatible with
many keyboard macro packages, third party tablet drivers, journaling
packages, and possibly Apple's future operating systems. In general,
unless there is a really good reason, and you plan to support the
program forever or the program is only for private use, if a tooltrap
exists that returns the value of a global, use the trap and not the
global. It will save you a lot of grief when the system changes.

If you care, profile your code, and see how it runs with direct access to
the global versus via the trap. You'll often find that doing ti the right
way doesn't actually cost you any speed.

If you are running under multifinder, WaitNextEvent returns mouseMoved as
a nullEvent with a bit set  (in the message field?, in the modifers
field?) if the mouse moved outside the region you hand WaitNextEvent. If
you are not running under multifinder, it does no harm to just call
GetMouse().


--- David Phillip Oster            --When you asked me to live in sin with you
Arpa: oster@dewey.soe.berkeley.edu --I didn't know you meant sloth.
Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu