pvf@bridge2.ESD.3Com.COM (Paul V. Fries) (07/08/89)
Sorry to ask again, I am sure I have seen this some time in the past. I need to know a "legal" way to determine the locations of the GEMDOS mouse variables. I have a mouse trapping program that was written for the particular ROMS that are in my 1040ST. As we all know, TOS 1.4 will soon be here. I want to fix up the program to be more general so I don't get bitten when the new TOS arrives. FYI My mouse trapping program implements a "gate" at the menu bar. To open the gate and enter the menu bar, the right button must be pressed while attempting to traverse the gate. All other mouse functionality remains the same. The program intercepts mouse packets from the keyboard processor and modifies the Y coordinate in the new packet to limit the vertical travel. It needs to know what GEMDOS has recorded as the mouse position in order to make the decision. The program is about 180 bytes of code written in Laser "assembly" language. NO "C" code is used. The in-line assembly code is linked as the very first and only object. Even init.o is not included, so the OS just dumps control at the first instruction. The program sets some hooks and then does a Ptermres() call (in assembly, of course). It is run from the auto folder, and has never seemed anything but invisible since, i.e., it seems quite bug-free to me. I would be happy to post the source if there is any interest. The functionality was inspired by some other mouse trapping program that I got from somewhere, but didn't like the particular way it was done. I wrote my program instead.
apratt@atari.UUCP (Allan Pratt) (07/11/89)
pvf@bridge2.ESD.3Com.COM (Paul V. Fries) writes: > I need to know a "legal" way to determine the locations of > the GEMDOS mouse variables. I have a mouse trapping > program that was written for the particular ROMS that are > in my 1040ST. As we all know, TOS 1.4 will soon be here. > I want to fix up the program to be more general so I don't > get bitten when the new TOS arrives. You can do this legally, but you might not be able to do it from the AUTO folder, and you can't do it legally the way you describe (linking into the trap and clobbering the Y movement value). What you should do is use the VDI exchange-mouse-movement-vector call. It will have the same effect as you describe, but will be legal. Another way is to use the negative Line-A variables... If you're a developer, get SALAD (Still Another Line A Document). If you aren't, then you should become one because you get cool stuff like Landon Dyer's assembler, my linker, my debugger, and SALAD. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
uace0@uhnix2.uh.edu (Michael B. Vederman) (07/14/89)
Speaking of mouse movement and the such... Is there a way to *prevent* the
AES from getting mouse clicks at the desktop? In other words, can one turn
off mouse packet handling to AES? Like taking over the AES mouse handler?
Unfortunately, the AES mouse handler is not at all documented (VDI, yes).
- mike
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACE