Polling the mouse

[Curry]

Scott Raney wrote:

> But did you actually try this?  It *doesn't* work that way in either
> MC or HC now.  If you don't see it, try increasing the loop count (you
> may need to at one zero for HC, and about 3 in MC/RR ;-)
> 
> My real question is, given that you're confused about this, how many
> other people must be, and if a lot, does this behavior really need to
> be preserved?

I tried this:

on mousedown
  put the mouse
  repeat 5 times
    wait 1 second
    put the mouse
  end repeat
end mousedown

In Revolution 1.1.1 Beta 1, it would accurately show if you had kept holding
the mouse all the time, had released it once, or had released and pressed it
down once more--but it wouldn't show "up" again if you released it the
second time. That's not too bad. But even better: adding "with messages" to
the wait achieved perfect accuracy.

Then I tried this:

on mousedown
  put the mouse
  repeat 5
    repeat with i=1000000 down to 1
    end repeat
    put the mouse
  end repeat
end mousedown

That time, it only said "down" and kept saying down, despite every effort to
make it do otherwise.

Adding "wait 1 millisec with messages" after the inner repeat loop, however,
made it perfectly accurate about the mouse button state. So, at least a bit
of tinkering can yield a great result. (I think I've used this technique to
use the polling function inside repeat loops also.)

As far as the question, should the behavior be maintained if people aren't
aware of the exact details, it misses an important point. People don't know
the exact behavior of some feature until they need it and try it. No one can
be on top of every detail at every time. (Except of course the great teams
that produce MC and Rev!) But you have to realize, this is your career and
your specialty. Every aspect of our lives involve technologies we use on a
daily basis but do not fully understand.

But people do have expectations about things which they use and care about,
even though they aren't always completely up to date or up to speed on the
details. And I'm betting that when people do need to try out this kind of
feature, this is what the vast majority would anticipate: that the mouse
simply returns "up" when it's up and "down" when it's down.

That's what I expect. Of course, absolute perfection is difficult, so I
would ask that the behavior aim for perfection and stop where it is
practical. If it behaves well in most situations and needs a bit of
tinkering now and then for special situations, just like any piece of
equipment, then it's acceptable.

I think it would be perfect if the capability were there for those people
who need to avoid the mouse polling functions in making the very
best-behaved software for the most savvy operating systems, but retaining
the ability to poll the mouse singly or in repeat statements for people who
aren't on such a strict "keyword diet".

I think that using the mouse, the mouseLoc, and similar functions once, a
few times in a handler, in a repeat loop, or at intervals after actions or
waits (adding "with messages" is no incovenience) is very important for
typical scripting as it has always worked.

Without these keywords and capabilities, the result wouldn't truly be xTalk
any more in my opinion. I don't want a situation in the future where I'm not
able to script a line like "repeat until the mouse is up." I want to be able
to avoid it when necessary, but I always want the option to be there. This
type of thing is why I'm here right now with this product in the first
place.

I consider the use of these functions to be typical scripting style. I want
a product that continues to support this style. I also appreciate being able
to use other methods when they are called for, but to my viewpoint, that
doesn't take away from the polling functions; it just means that they are
not suited for certain special situations.

I would assert that right now, they are adequate for the great majority of
situations, and those special situations are a minority. So, I think that
removing or disabling these polling functions would be a huge overreaction
to a finite problem. If something needs to be adjusted, that's okay, but the
adjustment shouldn't extend far beyond what's necessary to solve the
problem.

All I'm saying is that we need these functions. Let people avoid them when
necessary, but keep them full-strength and usable for when people do choose
to use them. How it's done technically doesn't matter too much as long as
the behavior is as close to the expected behavior as possible in most
situations--single use, multiple single uses over time in a handler, and in
repeat loops.

If I got mixed up in my previous post with the technical terms and the
synchronouslies, my apologies! :-) This time I've avoided all such lingo to
make sure it's clear what I'm proposing. In short, I'm opposed to
depracating the polling functions. (With the exception of the mouseClick,
which I couldn't care less about.) Suggesting that people don't use them for
serious applications on certain target operating systems is fine, but I'm
against disabling them in any way. (I'm trying to avoid the word "retain",
because I am not against modifying the underlying technology if the
modifications retain or improve the accuracy of the polling results.) As
long as that can be done, I will be a truly happy camper here in the Rev/MC
camp.

Curry Kenworthy