Mouse polling answers for Scott

[Scott Raney]

On Wed, 27 Feb 2002 Charles Silverman <csilverm at acs.ryerson.ca> wrote:

>   Thanks for not letting me off the hook :)
> 
> >At the very least, you have to answer the question: is asynchronous
> >(real time) polling of the mouse buttons with the mouse function
> >adequate, or is it important to preserve the event-based
> >implementation of HyperCard (and I thought SuperCard, though I haven't
> >actually tested that)?  In your case, I think the distinction would be
> >"is it acceptable for "the mouse" to return "up" even if the mouse had
> >been pressed down and up between sequential calls to the mouse
> >function?
> 
>   I need the entire queue of mouse events since each user action is
> significant for me. Some users have such a light and quick touch that it is
> significant. For other users, slight touches are accidental. So I've got  to
> catch and process everything. If we're talking about the same thing,
> SuperCard preserves the events as well.

Can someone please verify this?  We've had two anecdotal reports that
SC does *not* work this way.  Running Geoff's example script will
clear up the issue once and for all I think.

> There are times when I get rid of
> everything that's happened up until a point in order to start from a clean
> slate  with "flushevents."
> 
> Here's a shortened sample of how I register a user action...
> 
> On mousedown
>    repeat while the mouse is down
>    end repeat

I don't see the point of this: why not just handle mouseUp in the
first place?

>    -- user start scanning through three objects in order to select one
>    put "alphabet,wordlist,editor" into tObjects
>    repeat with loop = 1 to 3
>      set the threeD of fld (item loop of tObjects) to FALSE  --hilite field
>      if timedWait() then
>           --scan the options in the field
>          --- this might nest quite a bit deeper
>      end if
>      set the threeD of fld (item loop of tObjects) to TRUE --unhilite field
>    end repeat
> End mousedown
> 
> 
> Function timedWait
>     global gDwelltime --number of seconds to hilite the selection before
>                       --moving on to the next selection
>     put the seconds into tStartTime
>     repeat until the optionkey is down -- in case the loop goes forever :)
>        if the seconds - tStartStart > gDwellTime then return FALSE
>        if the mouse is down then

You will potentially miss this mouse down event if we switched to an
async mouse function (if it goes down and back up between sequential
calls), but not with the current event-based implementation.  Which of
course brings us to what is another key issue here: despite having
seen statements from various people about the unreliability of the
mouse function, we still *don't* have a reproducible example where it
returns the wrong value.  If it's as common as some people seem to
think it is, it should be possible to come up with such an example and
send in a bug report so that it can be fixed.

>               repeat while the mouse is down
>                  --- I might do something here in case
>                   ---  very spastic user can't release the switch
>               end repeat
>               return TRUE
>     end repeat
> End timedWait
> 
> > A related issue is with the "wait" command.  With the current
> >synchronous mouse function "wait until the mouse is down" will always
> >return when the user clicks.  With an async function it's possible
> >that you will miss a quick click because there may be a delay between
> >when the wait function is able to make sequential checks.  If the
> >mouse goes down and then back up in that interval, you'll miss it.
> 
> Then would doing "repeat while the mouse is down" be better than the wait.

But still vastly inferior to doing it the right way which is to use
mouseDown/mouseUp/mouseRelease, possibly in combination with "send
.. in" to implement a time out.  These are 100% reliable and will
also greatly improve the responsiveness of your application.  Doing it
this way would take no more lines of script than your example, though
it does require thinking slightly differently about the problem.
  Regards,
    Scott

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...