Polling the mouse

[Curry]

Scott Saults wrote:

> My 2¢?  Revolution should drop "the mouse" function, unless it can be made
> to work in a reliable, predictable way, as documented. I can live without it.

Why not take the second option? I say make it work in a reliable way--let it
just indicate the real-time mouse button position with a direct call. Drop
the HyperCard compatibility rather than dropping the function. (After all,
you'd lose a lot more compatibility by removing the whole thing than by
altering the behavior to be more straightforward and logical.)

I would rather have the mouse give the real position of the mouse--all these
buffered behaviors make no sense! As it has been pointed out, most of us
don't know the complex behaviors anyway and just expect it to give the mouse
value as it is at the time of being called. Surely no one would mind if the
behavior is changed, since the alternative considered is to get rid of the
whole thing!

I already told myself I'd shut up already on this issue after the last post,
but sometimes I muddle through a few posts without explaining my intended
point as clearly as I tried to, so here goes one more final shot at it.
These poor under-appreciated functions are part of the heart and soul of
xTalk, allowing us to handle the most common types of interactions in a very
intuitive fashion that's easy to learn and convenient to use--without
umpteen separate handlers for ups, downs, moves, etc. Come on, people, you'd
really rather do that than just say "until the mouse is up" or "if the mouse
is down" or "get the mouseH"? Are you really looking at how much you'll be
losing?

Just because HyperCard made the implementation imperfect and a pain to
continue to support compatibly doesn't mean that the concept, syntax, and
functionality isn't perfect; it is. Rather than dropping these functions and
statements that use these functions, I suggest that MetaCard alter the inner
workings and behavior to match what MetaCard needs, and forget about the
complex HC behavior. I would prefer simple, direct polling that showed the
true state, but something else close to that would also be fine--whatever
works for MetaCard, as close to true polling as possible.

Then, as far as I could tell, everyone could be happy--people who like
separate handlers for OS-friendliness or personal style could use them to
their heart's content and pretend the functions no longer exist; people who
appreciate the stylish and convenient power of the traditional statements
could enjoy them and make good use of them; and hopefully the MetaCard team
would have a straightforward way of implementing them that would be a lot
easier to support and remove the current problems.

I'm a big believer in these functions. They are a familiar and IMHO
necessary part of scripting, and other competitive languages for the non-C++
audience, like BASIC, have similar functions. Having two ways to handle
these types of interaction--in separate specific handlers and with functions
inside other handlers--is the norm. So we need to have both ways too. If the
tiny details of the traditional implementation cause problems, it's the tiny
details that need to go, but the functions really need to stay. Well, that's
it, I'm zipping it! I hope I've made a good case for the survival of these
"endangered species" of precious keywords.

Thanks,

Curry Kenworthy