Polling the mouse state

[Ian Summerfield]

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
>>>  stop,
>>>  i.e.
>> 
>> 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":

on mousedown
  global dragging
  put the short name of the target = "drag" into dragging
end mousedown

on mousemove x,y
  global dragging
  put x & "," & y into myPointIs
  if xyz
  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
end mousemove

on mouseup
  global dragging
  put false into dragging
end mouseup

on beeper
  beep
  send beeper to this card in 10 secs
end beeper

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.