Re: 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 <[EMAIL PROTECTED]>

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
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution