saj@chinet.chi.il.us (Stephen Jacobs) (04/01/89)
A while ago I asked for advice on how to sense mouse button pushes safely
and reliably. Lars-Erik Osterud suggested using evnt_multi set to return
on timer events to poll the button state. It's hard to explain exactly
how, but even that VERY conservative approach seemed to run afoul of timing
differences between window-moved messages and button pushes/releases
(I really don't understand this stuff). Anyway, based partly on the above-
mentioned conservative approach, I think I have a fairly general solution to
how to use mouse button pushes in non-forms-oriented situations. Here are
the principles:
1) Use the documented extended Line A variable to sense the mouse button
state whenever it might be interesting.
2) Debounce all button state changes (an evnt_timer() call for 10 millisec.
appears to be adequate).
3) Take no immediate action based on a mouse button state change. Instead
set a flag, look for AES messages and let the VDI do anything it might
have in progress. If appropriate, the routines that handle messages can
reset the action flag.
4) Only after everyone else has had a crack at the machine state take action
based on the mouse button state.
This approach seems conservative enough that I'll be using it automatically
from now on (I hate having to play for 2 weeks to get things to happen in
the right order). The hardware is fast enough to cover a LOT of conservatism.
Steve J.kbad@atari.UUCP (Ken Badertscher) (04/02/89)
In article <8086@chinet.chi.il.us> saj@chinet.chi.il.us (Stephen Jacobs) writes: |[stuff about evnt_multi problems monitoring mouse buttons deleted] |1) Use the documented extended Line A variable to sense the mouse button | state whenever it might be interesting. A better solution than using line A variables is to use the VDI vex_butv() call, inserting an interrupt handler of your own which saves the button states in your local variables and passes off to the original vector. After you have installed your handler via vex_butv(), the system will jsr to your code any time the mouse buttons' state changes. When you are done updating your local variables, you should jump through the vector that was returned by vex_butv() so that the system gets the button state change information as well. This is just a pet peeve of mine; people tend to indiscriminantly use the line-A variables rather than the VDI calls that are there. In most cases, it is not necessary (and sometimes dangerous) to use Line A variables. In this particular case, even if you're being very conservative with what you do with button changes, you may run into problems. The AES maintains its own button state information which is independant of the VDI/Line-A variables, and it is possible (if you aren't careful) to get "out of sync" with the AES. Good luck with your button handling code, Stephen! -- Ken Badertscher | #include <disclaimer> Atari R&D | No pith, just a path: Software Engine | {portal,ames,imagen}!atari!kbad