curry at kagi.com
Thu Feb 28 01:28:00 EST 2002
For the mouse() function, with direct polling, you'd never be stuck but you
might miss something. With event-driven (as it is now), you may get the
wrong answer, or even get stuck sometimes because of the limitations.
I was informed off-list that in some newer OS's, direct calls for the mouse
state are not even supported or recommended by the OS. So, how about a way
to accomodate both desired behaviors:
The engine keeps track of all the mouseup and mousedown events that happen
since the handler starts, not just to the very limited extent as with the
current behavior. Then have a global preference of simulating direct polling
behavior or getting events in order with each call.
If direct polling was simulated, the time of the call could be compared to
the time of the events, and the most recent state according to the events
would be returned. But without the current limitations, it would never
return the incorrect state or get stuck like it does now.
For the buffered event behavior, you could get the next event after the last
one your script had seen, no matter how many events had happened since.
The other advantage would be that it would work well with the newer OS's and
not make direct calls.
I'm not a techie and don't know how easy or difficult it would be to
implement, but if it would work, it would seem to solve a lot of the
(I would like to add that I agree to a certain extent with the other side of
the argument, that people should avoid overusing the mouse function and
using it in the wrong situations. I think it's especially good for students
and convenience in roughing something out quickly for testing, but also in
some special situations in serious scripts.
Still, it would be good to have a reliable behavior that met a wider range
of needs and returned a more reliable value, for when the function is used,
whether out of necessity or preference or whatever. It would be nice for it
to never lock up.)
More information about the Use-livecode