Polling the mouse

[Richard Gaskin]

> The short answer to your question is, don't use a repeat loop, use
> "send .. in" to draw the segments instead, and cancel the message if
> you get a mouseDown.
> 
> The long answer, and probably much more than you want to know, is that
> "the mouseClick" is really the problem here, not "the mouse".  "the
> mouse" could in theory be done asynchronously.  If this were changed
> you'd still have the performance issue to deal with (i.e., "repeat
> until" would never be as smooth as using mouseMove messages and would
> eventually cause the OS to start penalizing your app), but reliability
> wouldn't because this information can be queried directly from the OS
> on all platforms.  You'd also be subject to the normal behavior of
> async functions (e.g., in HC, "the mouse" returns "down" if the user
> clicked down anytime between when the handler started running and when
> the function is called, whereas an async implementation would only
> return "down" if it was actually down when you made the call).
> 
> The problem with "the mouseClick" is that of state management and
> event order: it has to wait for the mouse to go down and then back up.
> Worse, at least for HC compatibility, is that if you do something in a
> script that takes a few seconds and click twice in that interval, "the
> mouseClick" will return true *twice*.  This means that it's necessary
> to maintain a queue of these mouse events and check the whole queue
> each time the function is called to see if there is both a mouseDown
> and a mouseUp message in it, and pull them out as a pair if so.  And
> of course you can't just leave the rest of the events in the queue
> either, because some of them (like socket events and redraws) need to
> be handled independently of what the currently running handler is
> doing.  Doing this cross-platform is horrendously complicated, and
> results in compromized reliability for *everything*, not just the
> mouseClick function.  Which is why we want to (and plan to) remove
> this functionality, or at least substantially modify it to remove this
> queueing aspect (e.g., the mouseClick would return true only if you
> clicked down and up any time between the start of the handler and when
> you made the call, and once it returned true *all* state information
> would be tossed out so it wouldn't return true again until the user
> clicked again after the function returned true, even if they clicked
> multiple times before the first call).

This is the best explanation yet, and I've saved it to explain to clients
why so much of their code needs to be rewritten when moving stuff from
another xTalk.  They hate paying for it, but attempting to check the mouse
during a repeat loop is not reliable in MC, even though it works well in
other xTalks, and I try to tell them it's just a small tradeoff for gaining
the other 97.5% of the market (is the Mac really down to 2.5% as MediaMetric
reported two weeks ago?).

However, something that would be even more useful than this explanation are
a couple of good examples in the docs of how one would approach converting
such a handler.   The mental flip-flops needed to do this took me a fair
amount of trial and error to get down, and the time lost is something either
a client pays for or I absorb here, but regardless who's writing the check
it still feels like a loss when the same handler worked perfectly before
conversion.  

Given the background you provided I support the move, but anything that
could be done to reduce conversion costs would be very helpful.  As it is,
with complex projects it's sometimes easier to write something over from
scratch than pick your way through differences in syntax and object model.
There are many benefits to a complete rewrite (and with OS X and XP, most
projects need a UI overhaul anyway), but it's a hard sell for new clients
who don't understand how something can be "compatible" and "incompatible" at
the same time. :)

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Custom Software and Web Development for All Major Platforms
 Developer of WebMerge 1.9: Publish any Database on Any Site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc