Polling the mouse state
iansummerfield at btconnect.com
Wed Feb 20 23:42:01 EST 2002
On 20/2/02 2:50 pm, "Jim Hurley" <jphurley at jps.net> scribed:
> Hi Ian,
>>> I don't like the grab command, it seems to me program flow doesn't
>> 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.
Using the mousemove is no good. I want to suspect all the messages from
happening while I'm dragging a pin around on my timer plug. With mousemove
I'm effectively dropping back to an "idle" state between each call, I need
to stay in the handler, to do that I'm back to checking myself whether the
mouse is still down or not.
Try this as an example, call beeper from the message box to get the beeps
going, then the challenge is to make the drag work but suspect the beeps,
however, just killing the event is no answer, my program might have 30-40
different events pending and killing them all is out of the question.
Put in card script, and have a button called "drag":
put the short name of the target = "drag" into dragging
on mousemove x,y
put x & "," & y into myPointIs
then set the loc of the target to myPointIs
-- I have code here to check whether the object has intersected other
-- things, if so different drag handlers take over, so using the
-- drag command isn't on
put false into dragging
send beeper to this card in 10 secs
And all hell is let loose if a mouseup event is lost, as can happen if you
switch out of revolution with the mouse still down.
More information about the Use-livecode