Mouse polling

[David Vaughan]

Charles

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 2546 bytes
Desc: not available
URL: <http://lists.runrev.com/pipermail/use-livecode/attachments/20020226/c778066c/attachment.bin>