Avoiding mouse polls
Ken Norris (dialup)
pixelbird at interisland.net
Sat Dec 14 22:30: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).
> 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.
Yes, that's true, but I'm not sure I'm being understood. The problem doesn't
lie with level location, but with interrupting a continuous loop. The entire
sequence mentioned above is in a nested loop. The hilited objects don't just
sequence once, but loop continuously until the mouse is clicked. In other
words, if no mouseclick occurs, it continues the hiliting sequence until it
reaches the last object, then starts over, forever.
So far, I have still found no way to interrupt a continuous loop with an
action external to the loop. It was suggested that I change a global
variable, but I can't see a way to change _anything_ while the loop is still
Plus, in my case, due to the necessity of a single-switch solution the
interrupt must be caused by a click, however it happens.
At the most basic level:
-- AFAIK, no external action, other than cmd/. on a Mac,
-- can interrupt this.
...creates an endless loop.
How do I interrupt that with a click unless:
repeat until the mouseClick -- polls the mouse
...or unless there is another way of looping continuously to look for a
More information about the Use-livecode