Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: moving mouse pointer under program control Message-ID: <6476@hoptoad.uucp> Date: 9 Feb 89 11:13:07 GMT References: <17871@gatech.edu> <6443@hoptoad.uucp> <1858@helios.ee.lbl.gov> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 62 In article <1858@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >Then, pray tell, how would one go about writing a mouse driver? Forsooth, good sir, one should not, save it be a last resort! The mice I have seen which bore not the Apple label have pretended they did; or in the modern language, they have emulated the signals which Apple mice send to the host computer. In this way no new software whatsoever was required. This guarantees compatibility with future releases of the operating system, and removes any necessity for the user to install new software. In addition, no disk need be distributed with the product. It's a win from every direction. >If some new hardware device is to be used to move the mouse, then software >is going to be needed to move the pointer. Wrong. But let's say that for some reason your product simply can't emulate the Apple mouse hardware interface. I can't think of any good reason offhand, but perhaps there is one. Then you would have to write a mouse driver. How would one go about writing it? One could depend on undocumented Macintosh globals which are virtually guaranteed to go away at some point in the not-so-distant future; this approach would emulate the Mac mouse driver in software, writing to the same globals which are used by the built-in GetMouse etc. routines. Then a new version of the operating system comes along which changes the way those globals are used, and you, my friend, are SOL. That's what you get for violating the long-established rules by using undocumented globals. The same can be said if you write software which moves the mouse for other reasons; one OS rev and bang, your software is dead. The alternative is to ignore the globals and write new versions of the routines which currently return the mouse state and position. This is also technically illegal; it involves "tail patching". However, the probability that GetMouse, Button, et al., are traps which have "call from" checks built in is small, and though it's a judgment call, it seems to me you are less likely to have problems this way than by depending on magick globals. Note however, if you write application code that moves the mouse, you will not work with a mouse driver that takes this trap-patching approach. So, the serious user interface confomrity problems notwithstanding for the moment, moving the mouse from software by manipulating undocumented globals is also a loss because of compatibility issues. >I think your attitude about >withholding information about something so fundamental is ridiculous. >People should have the freedom to write software (for their own use) that >behaves according to their specification. Freedom? Was I talking about putting the hapless author in jail? I was only withholding my support for what I consider an extremely questionable software practice. Surely that is *my* freedom. >If you need more information, I have a routine that I >call SetMouse (as opposed to GetMouse) that does exactly what you want. Oh? It works on all future revisions of the Mac OS, and with all possible mouse drivers? Now it's your turn to be (as you said earlier) ridiculous. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Mere opinion without supporting argument is no more than the American Bandstand school of literary evaluation." -- Tom Maddox