On Wednesday, February 27, 2002, at 02:49 , you wrote:
I don't have the time to give a solid and detailed response to the
mousepolling controversy. Suffice it to say that I need to do detailed
mousepolling within repeat structures.
snip
On 13 February you wrote:
Hi,
This bit of code doesn't work right (though in Supercard it's fine) I've
seen recommendations for using "send" but don't I open up to other
inadvertent/undesirable user events or processes happening. I need to keep
the user focused within a specific loop. Am I missing something?
Here's the kind of code I'm talking about. In this example the script goes
into a btn and there's a single fld . Warning... This code has crashed Rev
and frozen my computer (Mac Pismo PB).
The larger purpose of this code is for the creation of single switch
software for kids who can't manipulate a keyboard but can press and release
switches. I've been doing this stuff for years in SuperCard. I need to
carefully scrutinize switch (mouse btn in this case) activity to accommodate
for a variety of behaviors. The code strategy below is what I traditionally
use for hiliting a series of objects (btns, flds, text within field, etc.)
one at a time, for a duration of time, and as well, using the amount of time
involved in mouse downs and ups to create multiple signal possibilities.
Any thoughts on this appreciated.
Both I and Rob Cozens (I think. I didn't keep the mail) replied seeking clarification of your requirement. I wrote (and Rob to similar effect):
Is it your intention that
- one click on the mouse does nothing (from the user view)
- two clicks within fifteen seconds generates a reward message, which disappears on mouseUp
- no other events are accepted after the first mouseClick until timeout or a second click on the same button
Since you did not respond to either message, I presume you solved your problem, but you are still seeking synchronous mouse functions without various other helpful people having had the opportunity to see if it might work differently :-)
What you MUST have is a solution to your interface requirement. Let us then find out if that solution entails particular programming features, rather than working the other way around. If it does, your argument to retain those features has more force, and Scott will have a clearer idea on an adequate implementation.
regards
David
