Polling the mouse state
jphurley at jps.net
Wed Feb 20 09:53:00 CST 2002
>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
>> I don't like the grab command, it seems to me program flow doesn't
>> Grab me
>> 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
>> 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
>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
More information about the use-livecode