Avoiding mouse polls

[David Vaughan]

On Sunday, Dec 15, 2002, at 14:40 Australia/Sydney, Ken Norris (dialup) 
wrote:

>
>> 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.
...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 
> 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
> running.
>
> 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
>   repeat
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
> end

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.

regards
David
>
> TIA,
> Ken N.
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>