Avoiding mouse polls
Ken Norris (dialup)
pixelbird at interisland.net
Sat Dec 14 13:54:01 EST 2002
Date: Sat, 14 Dec 2002 17:14:57 +1100
Subject: Re: Avoiding mouse polls
From: David Vaughan <dvk at dvkconsult.com.au>
> What is wrong with mouseUp and mouseRelease rather than polling for the
> mouseClick? You need to catch both because you can not predict (and do
> not care) where the mouse went down, but these will work, will they
> not? No object is involved (except for whatever you yourself are
> highlighting for them).
Well, if I keep it at the stack level, I won't need to know where the mouse
went down anyway. Plus, I'd still have to poll for the mouseRelease. How
else can I get the loop that hilites the objects to stop/move on to the next
set of objects?
I think we must have a way to detect a mouse action within the loop. I tried
changing var content, but the loop doesn't receive it while it's running.
> You can highlight objects by using a counter to iterate through the
> keys of an array from which you take the object IDs. That way, you have
> easy programmatic control of the object highlight sequence without
> having to fiddle with the code which actually orders the highlights.
So, you mean to put the loop (which emulates hiliting object choices) in a
mouse handler (or another handler that just loops) rather than the operation
Hmmm. That might work. The operation handlers can pass back the appropriate
values to go to the next step.
But, I still don't think a running loop can be stopped with a mouse switch
action unless you poll for it from inside the loop.
More information about the Use-livecode