XY

[Richard Gaskin]

Tereza Snyder wrote:
 
>>> Scott Raney has told us in the past that "repeat until the mouseClick" is
>>> not a good idea because it bolixes up the event handling in the engine. I've
>>> found that mouseMove works wonderfully in situations where you'd be tempted
>>> to use "repeat until the mouse is up" or similar loops.
>> 
>> While mousemove seems straight forward, how would one go about turning it on
>> and off as might be needed in the "XY function"?
>> 
> 
> something like: (NOT A REAL SCRIPT)
> 
> LOCAL tXY = false
> 
> on XY
> put true into tXY
> end XY
> 
> on mouseMove mX,mY
> if tXY then
> if the mouse is down then
> put false into tXY
> else 
> --  do XY stuff
> end if
> end mouseMove
> 
> another way: on XY, insert a script containing the code temporarily into the
> front, and remove it on mouseup

The latter is probably a good idea, even if it does seem unnecessarily
complicated at first glance.

But this lil' ditty opens up a debate about polling events vs. notification
events.  Scott is quick to remind us, and rightfully so 99.9999% of the
time, that messages that rely on polling (MC's event loop making repeating
queries of the OS) as opposed to notification (when the OS sends MC a
message) are a performance drain on the machine, esp. noticeable in
environments with true multitasking like OS X (as opposed to OS 9 and
earlier).

While this is merely factual and cannot be argued, it can be argued that
there are times when it's perfectly acceptable, if not beneficial, to rely o
polling.

The XY handler is a good example:

As normally written in HyperCard (as the first example showed), the xy
handler is invoked, runs while it's needed, and stops soon after when the
mouse is clicked.  Yes, it was eating far more clock cycles than needed
while it was running, but using it is inherently modal by nature anyway --
the only thing the user's doing is moving the mouse; as soon as they click
it's over.

In contrast, the addition of a mouseMove handler to provide the same effect
requires that the interpreter evaluate a variable flag everytime the mouse
is moved -- potentially several dozen times every second -- whether XY is in
use or not.

In an average work week you may be running XY only a few times, but that
flag will be evaluated every time the mouse moves, all day, every day.  I
would imagine the aggregate waste of clock cycles, however difficult to
notice, would be far greater by the end of the week using "mouseMove" over
"repeat until the mouseClick", no?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 1.9: Publish your database on the Web
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc