Polling the mouse state

[Jim Hurley]

>
>Message: 7
>Date: Tue, 19 Feb 2002 11:46:23 +0100
>Subject: Re: Boxes, Grids, & Snap to Objects
>From: Klaus Major <kmajor at metascape.org>
>To: use-revolution at lists.runrev.com
>Reply-To: use-revolution at lists.runrev.com
>
>Hi Ian,
>
>>  I don't like the grab command,  it seems to me program flow doesn't
>>  stop,
>>  i.e.
>>
>>  Grab me
>>  Beep
>>
>>  Will beep immediately even though you're still dragging the thing
>>  around the
>>  screen.  This means you'll need to use a mouseup handler to do the new
>>  location stuff instead.
>>
>>  I find it much better to hide the cursor, and set loc of the object
>>  needing
>>  dragging to the mouseloc,  this is done in a "repeat while the mouse is
>>  down" loop and lets me do clever things,  I can check if the mouseloc is
>>  within the bounds of another object, and if so hilite that object, etc.
>>  It's much more flexible.
>>  ...
>
>maybe you missed some of the previous posts, where experts (!) are
>advising to
>not poll the mouse-state.
>
>It is far more efficient to use the mousemove function.

This issue of polling the mouse state continues to crop up. I have 
had to avoid the use of the old HyperCard standby:

"repeat while the mouse  is down"

not so much because I worry about burdening the CPU but more 
importantly because there is a bug in the MC engine which causes it 
to fail quite regularly. (Very often the MC engine fails to recognize 
when the mouse the mouse state changes to up.) And Scott says that 
fixing this bug is not high on the priority list.

I regularly use "repeat until the mouseClick" without the same 
problems I experience with the mouse function. My question is: Does 
the advice to stay away from polling the mouse extend to the 
mouseClick function as well? Scott has warned that the mouse() 
function may/will be discontinued. How about mouseClick()? Is it also 
in jeopardy?
-- 
Jim Hurley