Avoiding mouse polls
dvk at dvkconsult.com.au
Sat Dec 14 22:50:01 EST 2002
On Sunday, Dec 15, 2002, at 14:40 Australia/Sydney, Ken Norris (dialup)
>> 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
>> 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
>> 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
> lie with level location, but with interrupting a continuous loop. The
> sequence mentioned above is in a nested loop.
...which is your first and biggest problem. Don't do it with a repeat
loop; use a continual process set via send-in-time. Later posts made
by myself, Dar Scott and Cubist should have explained this more
clearly. In fact, Cubist basically wrote the code.
> So far, I have still found no way to interrupt a continuous loop with
> 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
> Plus, in my case, due to the necessity of a single-switch solution the
> interrupt must be caused by a click, however it happens.
A click still comprises an "on" (mouseDown) and "off"
(mouseUp/mouseRelease) so those events can still be used.
> At the most basic level:
> on anyHandler
Do **not** use repeat. Use "send in N seconds" to repeat the message.
See Cubist's code and our other descriptions.
> -- AFAIK, no external action, other than cmd/. on a Mac,
> -- can interrupt this.
> end repeat
Actually, send-in-time has some theoretical problems (which you should
not encounter on your expected timings) about which I wrote to the
improve-list. I am hoping that we will, in V2.1 or 3.0, have a more
manageable co-operative multi-processing environment.
However, your problem is solvable today. Reread the posts on this topic
after this earlier one of mine above and feel free to write to me
directly if you think it is still not clear.
> Ken N.
> use-revolution mailing list
> use-revolution at lists.runrev.com
More information about the Use-livecode