robinson@pravda (Stephen M. Robinson) (02/03/89)
We are using THINK (LightSpeed) C 3 and need to do the following:
click on a Rect region, hide the cursor, move the mouse point
to another Rect (window) and show the cursor again (based upon
contents of the first Rect region)
We know about HideCursor and ShowCursor in QuickDraw but cannot
figure out how to get the mouse point to move without moving the
physical mouse. We have found low level things like CrsrPin and
VIA addresses but have no idea how to use this info if it's even
pertinent. Any help is appreciated.
-----------------------------------
Stephen M. Robinson
School of Information and Computer Science, Georgia Institute of Technology
Atlanta, GA 30332
UUCPNet: ...!{uiucdcs,akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}
!gatech!pravda!robinson
CSNet : robinson@pravda.gatech.edu
Phone : (404)894-8932
-----------------------------------robinson@pravda.gatech.edu (Stephen M. Robinson) (02/03/89)
In article <17871@gatech.edu> robinson@pravda (Stephen M. Robinson) writes: >We are using THINK (LightSpeed) C 3 and need to do the following: > > click on a Rect region, hide the cursor, move the mouse point > to another Rect (window) and show the cursor again (based upon > contents of the first Rect region) > Ooops! I forgot to mention that we are using a color MacII if that matters... smr
tim@hoptoad.uucp (Tim Maroney) (02/04/89)
In article <17871@gatech.edu> robinson@pravda (Stephen M. Robinson) writes: >We are using THINK (LightSpeed) C 3 and need to do the following: > > click on a Rect region, hide the cursor, move the mouse point > to another Rect (window) and show the cursor again (based upon > contents of the first Rect region) Don't. In the Mac metaphor this is the equivalent of grabbing the user's finger and jerking it around. The mouse is not to be moved under software control except for helping the disabled. If you need to indicate something else as a result of a click, then use a rolling outline like MacPaint selections, a flashing hilite, or some other technique that doesn't violate the guidelines. I have spoken with people who used mouse-moving software on other computers and the results were *always* confusing and misleading, even to wizards. I know how to do this, but I'm not going to tell you, and there are good reasons Apple doesn't document it either. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "I slept with Faith, and found a corpse in my arms on awaking; I drank and danced all night with Doubt, and found her a virgin in the morning." -- Aleister Crowley, THE BOOK OF LIES
cbm@well.UUCP (Chris Muir) (02/08/89)
In Article 4603 in comp.sys.mac.programmer,
robinson@pravda (Stephen M. Robinson) asks about moving mouse pointer
under program control.
A (bad, but works) Pascal example:
procedure SetMouse (where: point);
var
LowGlob: integer;
LowMem: ptr;
PointPtr: ^point;
finalTicks: longint;
const
{some dangerous low-memory-global equates}
MBState = $172; {byte}
MTemp = $828; {point}
RawMouse = $82c; {point}
Mouse = $830; {point}
CrsrNew = $8ce; {byte}
CrsrCouple = $8cf; {byte}
Couple = $ff; {value for CrsrCouple}
Uncouple = $00; {value for CrsrCouple}
begin
LocalToGlobal(where); {Get ready to restore old mouse position}
LowMem := pointer(RawMouse); {point to low memory}
PointPtr := @LowMem^; {treat it as a point}
PointPtr^ := where; {store saved mouse position into it}
LowMem := pointer(MTemp); {point to low memory}
PointPtr := @LowMem^; {treat it as a point}
PointPtr^ := where; {store saved mouse position into it}
LowMem := pointer(CrsrNew);
LowMem^ := $ffff; {both CrsrNew & CrsrCouple}
Delay(5, finalTicks); {let the cursor catch up}
end; {SetMouse}
All the usual cautions about the User Interface Police apply.
B
--
_______________________________________________________________________________
Chris Muir | "There is no language in our lungs
{hplabs,pacbell,ucbvax,apple} | to tell the world just how we feel"
!well!cbm | - A. Partridgebeard@ux1.lbl.gov (Patrick C Beard) (02/08/89)
In article <6443@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <17871@gatech.edu> robinson@pravda (Stephen M. Robinson) writes: >>We are using THINK (LightSpeed) C 3 and need to do the following: >> >> click on a Rect region, hide the cursor, move the mouse point >> to another Rect (window) and show the cursor again (based upon >> contents of the first Rect region) > >Don't. In the Mac metaphor this is the equivalent of grabbing the >user's finger and jerking it around. The mouse is not to be moved >under software control except for helping the disabled. If you need to >indicate something else as a result of a click, then use a rolling >outline like MacPaint selections, a flashing hilite, or some other >technique that doesn't violate the guidelines. > >I have spoken with people who used mouse-moving software on other >computers and the results were *always* confusing and misleading, even >to wizards. I know how to do this, but I'm not going to tell you, and >there are good reasons Apple doesn't document it either. >-- >Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim Then, pray tell, how would one go about writing a mouse driver? If some new hardware device is to be used to move the mouse, then software is going to be needed to move the pointer. 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. Commercial software MUST follow the guidelines as set down by Apple, to be accepted by the Mac community. Anyone with access to MPW has all the information needed to move the mouse via software control. Just look in SysEqu.a for anything having to do with the Mouse. If you need more information, I have a routine that I call SetMouse (as opposed to GetMouse) that does exactly what you want. +----------------------------------------------------------------+ \ Patrick Beard "Badges? \ \ Berkeley Systems I ain't got to show you... \ \ PCBeard@lbl.gov ...NO STINKING BADGES!" \ + ---------------------------------------------------------------+
rubinoff@linc.cis.upenn.edu (Robert Rubinoff) (02/08/89)
In article <6443@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >....The mouse is not to be moved >under software control except for helping the disabled. This brings up a question I've had for a while: how do you use the "Easy Access" init? I have it in my system folder, but I can't figure out any way to activate it. I don't have the new manuals that came with System 6.0, so I presume this is described there. Does anyone know how to use this? Robert
tron@wpi.wpi.edu (Richard G Brewer) (02/08/89)
>This brings up a question I've had for a while: how do you use the >"Easy Access" init? I have it in my system folder, but I can't figure out >any way to activate it. I don't have the new manuals that came with System >6.0, so I presume this is described there. Does anyone know how to use this? > > Robert As I recall, you must type [command][option][shift][clear] simultaneously. the mouse functions can then be controlled thru the keypad... - Rick +----------------------------+--------------------+--------------------+ | Richard G. Brewer (TRON) | Power through | rbrewer@wpi.bitnet | | WPI Box 149 | better design | tron@wpi.wpi.edu | | 100 Institute Rd. | and engineering. +--------------------+ | Worcester, Ma 01609-2280 +--------------------+ President: | | (508) 792-3231 | VaNDaL's SaCk | The Apple Guild | +----------------------------+--------------------+--------------------+ | . . . E N D O F L I N E . . . | +----------------------------------------------------------------------+
lsr@Apple.COM (Larry Rosenstein) (02/08/89)
In article <7728@netnews.upenn.edu> rubinoff@linc.cis.upenn.edu.UUCP (Robert Rubinoff) writes: > >This brings up a question I've had for a while: how do you use the >"Easy Access" init? I have it in my system folder, but I can't figure out There are 2 independent features: (1) If you press the left shift key 5 times in a row, you will get a small u-shaped icon in the menu bar. Now, whenever you press a modifier key (shift, option, etc.) the key will stick down until you hit a non-modifier key. If you hit a modifier twice in a row, it will stick down until you hit the modifier a 3rd time You can turn this off by hitting shift 5 times in a row, or by hitting 2 keys at once. (2) If you hit command-shift-clear (on the keypad), then you can use the keypad keys to move the mouse pointer. The 5 on the keypad is the mouse button; the surrounding keys move the pointer in the appropriate direction; 0 locks the mouse button down; and period releases it. Hitting command-shift-clear turns this off. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
tim@hoptoad.uucp (Tim Maroney) (02/09/89)
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
robinson@pravda.gatech.edu (Stephen M. Robinson) (02/10/89)
Dear Tim: Since you did not deem it worthy of your time to respond to my personal note to you and since you continue to sit in your ivory tower and haughtily spout off about OS revs, compatibility, etc. I will reply via a more public forum. First, I am not a "hapless author" with little idea of what I am doing. What in fact I am doing is using the computer as a tool to study human behavior. As a computer scientist I am concerned with the esoteric and practical issues of writing portable code and such. However, I am also concerned with getting the computer to serve *me* and not vice versa. I needed a way of moving the mouse pointer under program control (and no thanks to you now I have it). Nothing less, nothing more. If I want to write an exploratory program that is subsequently washed out by a new OS rev, that is my concern. It serves my current research needs. It seems that if you are really in the business of making computers useful you should be willing to help another competent professional attain that end in the way best suited to his/her needs at the time. Your attitude is not conducive to the cooperation for which this kind of news group was set up. I don't mind being warned about what I'm getting myself into nor do I mind opinions about what should go into a good interface but the judgemental attitude I can do without. Stephen Robinson
lsr@Apple.com (Larry Rosenstein) (02/10/89)
TIm is exactly right when he points out the compatibility dangers of
moving the mouse under program control. If you are doing this for a
personal program, then go ahead and blast away at low memory. Just don't
complain to us if it breaks in a future system.
If you are doing this in a program that you distribute widely, then think
twice. At least, mention this "feature" or provide a way to turn it off.
I personally would hesitate to use a program that moves the mouse
programmatically. For one thing, I hate when a program "takes control" of
the cursor. (The old FEdit did this when it hid the cursor while starting
up.)
Also, I wouldn't be able to trust a program that moved the mouse
programatically. (What other evil things might it do?) I have come to
realize that when choosing software, it is best to consider the quality of
the program and/or the reputation of the programmer(s), even over the feature lists.
The only quibbles I have with Tim's message are (1) I don't think you
could implement a mouse replacement soley by patching traps (GetMouse,
Button, et al); you would need to replace the cursor handling code as
well, and (2) I think GetMouse, Button, et al are more likely to be "come
from" patched that he says.
Larry Rosenstein, Apple Computer, Inc.
Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1SIAC@applelink.apple.com (Eric Ulevik) (02/10/89)
First, I do not recommend moving the mouse pointer under program control. However, In article <6476@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: > >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? > [ ...don't do it! You'll be incompatible!] For Macintosh computers since the SE - those using the Apple Desktop Bus - it is possible to build ADB devices, such as trackballs, and write software to respond to this device, such as by moving the mouse pointer. Documentation to get you started is in Inside Macintosh Volume 5 Chapter 19, and Technical Notes 143, 160 and 206. Eric Ulevik email: SIAC@applelink.apple.com -- The above comments are mine!--
tim@hoptoad.uucp (Tim Maroney) (02/11/89)
In article <632@internal.Apple.COM> SIAC@applelink.apple.com (Eric Ulevik) writes: >First, I do not recommend moving the mouse pointer under program control. > >However, > >In article <6476@hoptoad.uucp> tim@hoptoad.uucp (Tim Maroney) writes: >> >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? >> [ ...don't do it! You'll be incompatible!] > >For Macintosh computers since the SE - those using the Apple Desktop Bus - >it is possible to build ADB devices, such as trackballs, and write software >to respond to this device, such as by moving the mouse pointer. > >Documentation to get you started is in Inside Macintosh Volume 5 Chapter >19, and Technical Notes 143, 160 and 206. Oh, come on! First of all, you mean chapter 20. Second, none of the documentation you mentioned has anything to do with moving the cursor. The Technical Notes are particularly irrelevant to this issue; #143 says "Don't call ADBReInit on the SE with System 4.1", #160 is about remapping the keyboard for chrissake, and #206 is a few miscellaneous questions and answers which have nothing to do with mouse devices. There is one , count them, one mention of moving the cursor in IMv5ch20: "The ADB driver should handle the ADB command passed to it and store any resulting input data by an appropriate action, such as by posting an event or moving the cursor." These are describing what the standard keyboard and mouse driver do, respectively, for purposes of example. There's not a word about how to move the cursor. My original message was correct; if you want to develop your own mouse, you should simply try to be hardware compatible with the Apple mouse. Like the existing optical mice for the Mac, you would be well advised to come up with both a Mac Plus version and an ADB version. If you try to develop your own driver, you are asking for compatibility trouble and for needless user inconvenience. Your message does not show what it claims to show, and in fact contains references so misleading they suggest a deliberate attempt to deceive. I wonder why it was posted at all, since it says exactly nothing. -- Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim "Jesus died for somebody's sins, but not mine." -- Patti Smith
cbm@well.UUCP (Chris Muir) (02/12/89)
In Article 4733 in comp.sys.mac.programmer, tim@hoptoad.uucp (Tim Maroney) writes: >My original message was correct; if you want to develop your own mouse, >you should simply try to be hardware compatible with the Apple mouse. >Like the existing optical mice for the Mac, you would be well advised >to come up with both a Mac Plus version and an ADB version. If you try >to develop your own driver, you are asking for compatibility trouble >and for needless user inconvenience. What about digitizing tablets? They would want to be connected by ADB, but would want to use absolute positioning, not the relative positioning of a mouse. There have also been some controls that hide the mouse cursor while you adjust a value using the mouse, then it repositions the mouse cursor to where you started when you let up on the button. Look at the "numerical" in Opcode or Intelligent Music software. -- _______________________________________________________________________________ Chris Muir | "There is no language in our lungs {hplabs,pacbell,ucbvax,apple} | to tell the world just how we feel" !well!cbm | - A. Partridge
CXT105@PSUVM.BITNET (Christopher Tate) (02/12/89)
In article <630@internal.Apple.COM>, lsr@Apple.com (Larry Rosenstein) says: >TIm is exactly right when he points out the compatibility dangers of >moving the mouse under program control. If you are doing this for a >personal program, then go ahead and blast away at low memory. Just don't >complain to us if it breaks in a future system. I have one minor point to bring up here: the exceptionally popular game "Crystal Quest" moves the cursor to the center of the screen at the start of every level. I discovered this when Pyro kicked in after I left the game paused too long. The cursor came back when Pyro quit, and Crystal Quest never again called HideCursor. I've never had any trouble running CQuest on any machine I've had access to, although I have been using exclusively Systems 4.2 and 6.0.2.... ------- Christopher Tate | etaT rehpotsirhC Bitnet: cxt105@psuvm | mvusp@501txc :tentiB Uucp: ...!psuvax1!psuvm.bitnet!cxt105 | 501txc!tentib.mvusp!1xavusp!... :pcuU Internet: cxt105@psuvm.psu.edu | ude.usp.mvusp@501txc :tenretnI
SIAC@applelink.apple.com (Eric Ulevik) (02/12/89)
In my previous message, I meant to point out that people developing ADB devices _can_ write drivers for them. Although IM and the Tech Notes do not provide all the information you need on how to do this, in TN 206 it tells you who to talk to to get the information that you need to develop ADB devices. Eric Ulevik email: SIAC@applelink.apple.com -- The above comments are mine!--
topping@dinghy.cis.ohio-state.edu (brian e. topping) (02/12/89)
Hello all. I have been watching this discussion about moving the mouse under program control, have heard, and understand, why you would not want to do this, can understand why the person wants to do it, etc, etc. One way to do this that I have not heard is using the toolbox event manager's journaling mechanism. Is this now considered bad voodoo by Apple? As is obvious from this post, I know little about it other than I have read about writing a journaling device driver in IM and MacTutor, and have enjoyed the few tutorials that actually do this. Not that my opinion matters, but I personally like the fact that the journalling mechanism is there, if for no other reason than it allows options. Comments welcome.... -bri