drvaughan55 at mac.com
Tue Feb 26 16:54:01 EST 2002
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.
On 13 February you wrote:
This bit of code doesn't work right (though in Supercard it's fine)
seen recommendations for using "send" but don't I open up to other
inadvertent/undesirable user events or processes happening. I need to
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
into a btn and there's a single fld . Warning... This code has crashed
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
switches. I've been doing this stuff for years in SuperCard. I need to
carefully scrutinize switch (mouse btn in this case) activity to
for a variety of behaviors. The code strategy below is what I
use for hiliting a series of objects (btns, flds, text within field,
one at a time, for a duration of time, and as well, using the amount of
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 2546 bytes
Desc: not available
More information about the Use-livecode