canuck@portia.Stanford.EDU (William Stocker) (06/05/90)
I'm writing a Mac program in THINK Pascal 3.0, and need to force the mouse to a particular screen location. I'm sure it's against Apple's guidelines (there's no SetMouse command I can find in Inside Mac I-V), but there's a good purpose for it -- trust me! Any help on this matter would be greatly appreciated --Will
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/05/90)
In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >I'm writing a Mac program in THINK Pascal 3.0, and need to force the >mouse to a particular screen location. I'm sure it's against Apple's >guidelines (there's no SetMouse command I can find in Inside Mac I-V), >but there's a good purpose for it -- trust me! DON'T DO IT. It's *very* bad technique, and your application won't run, besides. To answer your question: You can change the pointer's location by changing low-memory global variables. Which ones? I'm not sure; how you access them depends on what compiler you're using. I'm not familiar with THINK Pascal. Be warned that an application that changes low-memory globals has written its own death sentence. It will do nasty things to systems. Besides, to have a program move the pointer for you is like having a robot grab your hand and move it around for you. The pointer is the user's `hand': he should have free, unconstrained movement of it at all times. Tell me what, exactly, this `good purpose' is that you've thought up, and I and millions of other Netters will help you come up with a more proper way of doing it. << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
mxmora@unix.SRI.COM (Matt Mora) (06/05/90)
In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location. I'm sure it's against Apple's >>guidelines (there's no SetMouse command I can find in Inside Mac I-V), >>but there's a good purpose for it -- trust me! > > DON'T DO IT. It's *very* bad technique, and your application > won't run, besides. [good explanation of why not to deleted] >-- >| Brian S. Kendig \ Macintosh | Engineering, | bskendig | From page 84 of the UMPG. From: cbm@well.UUCP (.i.Chris Muir;) Subject: Re:.c. Modifying the mouse input (SetMouse codein pascal) Summary: Here's the compliment to GetMouse. Here's the other side of GetMouse, SetMouse: 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 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} Note that it uses undocumented low memory globals. -- ___________________________________________________________ Matthew Mora SRI International mxmora@unix.sri.com ___________________________________________________________
rdd@walt.cc.utexas.edu (Robert Dorsett) (06/06/90)
In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >Be warned that an application that changes low-memory globals has >written its own death sentence. It will do nasty things to systems. ^^^^ may >Besides, to have a program move the pointer for you is like having a >robot grab your hand and move it around for you. The pointer is the >user's `hand': he should have free, unconstrained movement of it at >all times. > >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. Games. It's often desirable to hide the pointer while the user goes into another input mode (e.g., Flight Simulator). It is only reasonable to have the cursor appear at the last position it disappeared in (particularly on a large screen). The current hidecursor and showcursor routines do not do this; thus, we must. Being able to set the mouse *value* can also serve to simplify data-gathering, should the mouse be used as a *control*. "Let the user look for it" is not friendly OR reasonable. In my game, for instance, there's a complex, dense data entry display: the mouse can EASILY get lost. The user will normally want to "disappear" the mouse at a certain point, and have it reappear at the same point. The lack of an ability to do this can really affect the utility of the game. BTW, have the low-memory cursor routines been verified to have EVER killed a machine? Last system I've tried them on was a iicx. They've worked on 128's, 512's, Plus's, SE's, II's, IIX's, and IIcx's... Why won't Apple just provide calls to do this sort of thing, and make life more comfortable? I know games don't count for jack sh*t in Apple's corporate philosophy, but it really would be appreciated. :-)
philip@Kermit.Stanford.EDU (Philip Machanick) (06/06/90)
In article <30981@ut-emx.UUCP>, rdd@walt.cc.utexas.edu (Robert Dorsett) writes: > In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > >Tell me what, exactly, this `good purpose' is that you've thought up, > >and I and millions of other Netters will help you come up with a more > >proper way of doing it. > > Games. It's often desirable to hide the pointer while the user goes into > another input mode (e.g., Flight Simulator). It is only reasonable to have > the cursor appear at the last position it disappeared in (particularly on > a large screen). The current hidecursor and showcursor routines do not do > this; thus, we must. Being able to set the mouse *value* can also serve to > simplify data-gathering, should the mouse be used as a *control*. > > "Let the user look for it" is not friendly OR reasonable. In my game, for > instance, there's a complex, dense data entry display: the mouse can EASILY > get lost. The user will normally want to "disappear" the mouse at a certain > point, and have it reappear at the same point. The lack of an ability to do > this can really affect the utility of the game. It sounds to me as if you are really arguing that there are times when you'd rather not have a Mac-style mouse. Rather than setting the mouse position, maybe the "logical" thing would be to temporarily metamorphose the mouse into some other device (e.g., a virtual joystick) and then recover the mouse afterwards. This could be a fun project for someone to tackle in their spare time. The reason I would prefer it if Apple _didn't_ introduce an easy way of setting the mouse position is the standard Mac interface is based around a model of mouse only goes where you put it. Other interfaces I've used aren't. You can get used to either, but to have both in one environment would be totally confusing (if it's easy to do, people will do it). Philip Machanick philip@pescadero.stanford.edu
smith@canon.co.uk (Mark Smith) (06/06/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location. I'm sure it's against Apple's >>guidelines (there's no SetMouse command I can find in Inside Mac I-V), >>but there's a good purpose for it -- trust me! > DON'T DO IT. It's *very* bad technique, and your application > won't run, besides. >[ ... ] >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. This is something that's bugged me for ages. There *are* valid reasons for moving the mouse pointer under program control, mainly when you are using the mouse to provide relative motions, rather than screen positions. A perfect example of this is the old game Lode Runner, where you indicate the direction of the man on the screen by pushing the mouse in the appropriate direction. The man then keeps going in that direction until the mouse is pushed in another direction. In the game, the pointer is visible on the screen. I wondered why, since the actual pointer position was irrelevant, until I was playing it once and managed to get the pointer flush against one side of the screen, and couldn't go that way anymore. Obviously, what the designers would have preferred to do was hide the pointer and keep throwing it back to the middle of the screen. I appreciate that moving the pointer by software isn't normally a good thing, but it seems to me that they should have discouraged it in the documentation, and perhaps forced you to hide the pointer before doing it, rather than making it impossible. I also ran into this problem when writing an emulator for a piece of graphics hardware which ran in a window on the Mac. Since the thing being emulated allowed the pointer to be moved, I had to as well. ==================================================================== Mark Smith Canon Research Centre Europe smith@canon.co.uk 19 Frederick Sanger Road ..ukc!uos-ee!canon!smith Guildford Surrey UK -------------------------------------------------------------------- "We always planned to ease ourselves into pure research anyway..." -- David Cronenberg, _Dead Ringers_
paulr@syma.sussex.ac.uk (Paul T Russell) (06/06/90)
From article <16995@phoenix.Princeton.EDU>, by bskendig@phoenix.Princeton.EDU (Brian Kendig): > In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location. I'm sure it's against Apple's >>guidelines (there's no SetMouse command I can find in Inside Mac I-V), >>but there's a good purpose for it -- trust me! > > DON'T DO IT. It's *very* bad technique, and your application > won't run, besides. I know you shouldn't do it, but there are times when it is justified. Here is a Pascal implementation of SetMouse (watch out - here come the Thought Police!)... unit UMouseStuff; { mouse utilities } interface procedure SetMouse (pt: Point); { move the current cursor position to the given point } implementation const { low memory globals } jCrsrTask = $08EE; { ProcPtr } MTemp = $0828; { Point - Low Level interupt mouse location } RawMouse = $082C; { Point - unprocessed mouse location } Mouse = $830; { Point - processed mouse location } CrsrNew = $08CE; { char - set != 0 if mouse has moved } CrsrCouple = $08CF; { char - set = 0 if cursor not allowed to move } type PointPtr = ^Point; { a pointer to a point } {--- private functions for accessing low memory globals ---} function Get_MTemp: Point; begin Get_MTemp := PointPtr(MTemp)^; end; { Get_MTemp } procedure Set_MTemp (pt: Point); var ptp: PointPtr; begin ptp := PointPtr(MTemp); ptp^ := pt; end; { Set_MTemp } function Get_RawMouse: Point; begin Get_RawMouse := PointPtr(RawMouse)^; end; { Get_RawMouse } procedure Set_RawMouse (pt: Point); var ptp: PointPtr; begin ptp := PointPtr(RawMouse); ptp^ := pt; end; { Set_RawMouse } function Get_Mouse: Point; begin Get_Mouse := PointPtr(Mouse)^; end; { Get_Mouse } procedure Set_Mouse (pt: Point); var ptp: PointPtr; begin ptp := PointPtr(Mouse); ptp^ := pt; end; { Set_Mouse } procedure Set_CrsrNew; var p: Ptr; begin p := Ptr(CrsrNew); p^ := 1; end; procedure SetMouse (pt: Point); begin Set_MTemp(pt); { set both of these low memory mouse positions to the new point } Set_RawMouse(pt); { (this prevents scaling) } Set_CrsrNew; { flag that the mouse has moved } end; { SetMouse } end. -- Paul Russell, Department of Experimental Psychology University of Sussex, Falmer, Brighton BN1 9QG, England Janet: paulr@uk.ac.sussex.syma Nsfnet: paulr@syma.sussex.ac.uk Bitnet: paulr%sussex.syma@ukacrl.bitnet Usenet: ...ukc!syma!paulr
rsholmes@rodan.acs.syr.edu (Rich Holmes) (06/07/90)
In article <1990Jun6.083741.4740@canon.co.uk> smith@canon.co.uk (Mark Smith) writes >A perfect example of this is the old game Lode Runner, where >you indicate the direction of the man on the screen by pushing the mouse >in the appropriate direction. The man then keeps going in that direction >until the mouse is pushed in another direction. Which is like using a screwdriver to pound in a nail. For a situation like this, why not use two keyboard keys to indicate left or right? In fact, why not left arrow and right arrow? Hey, it's a crazy idea, but it just might work... Remember: just 'cause it's a Mac program doesn't mean you have to use the mouse to do everything. They sold you the keyboard for a reason. The mouse is a pointing device. Please don't use it for other things. - Rich Holmes
rubin@cbnewsl.att.com (Mike Rubin) (06/07/90)
In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location.... >>but there's a good purpose for it -- trust me! > >Besides, to have a program move the pointer for you is like having a >robot grab your hand and move it around for you. The pointer is the >user's `hand': he should have free, unconstrained movement of it at >all times. > >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. Well, X-Windows has a call to "warp" (as in warp drive) the mouse pointer. Most X-based user interfaces think that if you put up a modal dialog box, you should move the mouse pointer into the dialog (probably over the default button) and restore its old position after the dialog goes away. This is a religious question and should really be user-settable behavior. (Hmm... it could probably be coded as an INIT, but it's beyond my skill. Any takers?) The Mac OS was designed for a small screen where one swipe of the mouse could always get you to a dialog box in the middle of the screen. X was designed for big displays where moving across the screen is more tedious. --Mike Rubin <mike@attunix.att.com>
jholt@adobe.COM (Joe Holt) (06/07/90)
Here is a very short routine which illustrates how to position the cursor.
It is written in Think C. I'll make no judgements regarding who should and
who shouldn't have this knowledge. Enjoy, all.
joe holt
---------- CUT HERE FOR MOUSETO.H ----------
/**************************************************************************
***
*** MouseTo.h
***
*** Position mouse to absolute screen location
***
*** History:
*** jhh jan 90 -- quickie pass
***
***/
#ifndef _H_MOUSETO
#define _H_MOUSETO
/**************************************************************************
**
** Public Functions
**
**/
void
MouseTo(int x, int y);
#endif /* ifndef _H_MOUSETO */
---------- CUT HERE FOR MOUSETO.C ----------
#include "MouseTo.h"
extern Point MTemp : 0x828;
extern Point RawMouse : 0x82C;
extern unsigned char CrsrNew : 0x8CE;
extern unsigned char CrsrCouple : 0x8CF;
/**************************************************************************
***
*** void MouseTo(int x, int y);
***
*** Move the mouse cursor to <x>, <y>. Takes effect immediately.
***
*** History:
*** jhh jan 90 -- quickie pass based on Apple docs
***
***/
void
MouseTo(int x, int y)
{
asm {
move.w y, D0 ; new vertical position
swap D0
move.w x, D0 ; new horizontal position
move.l D0, MTemp
move.l D0, RawMouse
move.b CrsrCouple, CrsrNew
}
}broe@plains.UUCP (Paul Broe) (06/07/90)
Lode Runner will let you use keyboard controls. In this case, I think keyboard control is *much* better (and faster response time don't hurt!). -- /---------------------signature version 3.5----------------------------------/ / "I have seen my next computer, and it is the Amiga 3000." - me / / MS-DOS... ick! Waiting for system 7.0 <broe@plains.nodak.edu> / / hp 15c -> 41cx -> 48sx Apple //c -> Mac SE (soon) Amiga 3000 /
philip@Kermit.Stanford.EDU (Philip Machanick) (06/07/90)
In article <1990Jun6.190840.23732@cbnewsl.att.com>, rubin@cbnewsl.att.com (Mike Rubin) writes: > Well, X-Windows has a call to "warp" (as in warp drive) the mouse pointer. > Most X-based user interfaces think that if you put up a modal dialog box, > you should move the mouse pointer into the dialog (probably over the > default button) and restore its old position after the dialog goes away. > > This is a religious question and should really be user-settable behavior. > (Hmm... it could probably be coded as an INIT, but it's beyond my skill. > Any takers?) > The Mac OS was designed for a small screen where one swipe of the mouse > could always get you to a dialog box in the middle of the screen. > X was designed for big displays where moving across the screen is > more tedious. I regularly use both Mac and X. When I first started using X, I found warping very confusing - I often lost the cursor - but you get used to anything. I think it would be a mistake to have both alternatives in 1 system. My alternative for large screens would be to warp objects of interest to the cursor, which is more in keeping with the Mac philosophy of putting the user in control. Some examples: Instead of "beep" when you click outside a modal dialog, the dialog warps to the cursor. Instead of having to find the menu bar from the bottom of the screen, COMMAND-click jumps the menu bar to the cursor (I've got an idea of how this could be done without too much screen clutter - ask if interested, but no, I'm not going to program it). Maybe the detail needs some work, but I like the general idea. I'm not arguing whether Mac is better or worse than X (please don't set me off on that). I'm arguing for maintaining a consistent interface. Philip Machanick philip@pescadero.stanford.edu
smith@canon.co.uk (Mark Smith) (06/07/90)
rsholmes@rodan.acs.syr.edu (Rich Holmes) writes: >In article <1990Jun6.083741.4740@canon.co.uk> smith@canon.co.uk (Mark Smith) writes >>A perfect example of this is the old game Lode Runner, where >>you indicate the direction of the man on the screen by pushing the mouse >>in the appropriate direction. The man then keeps going in that direction >>until the mouse is pushed in another direction. >Which is like using a screwdriver to pound in a nail. >For a situation like this, why not use two keyboard keys to indicate left or >right? In fact, why not left arrow and right arrow? >Hey, it's a crazy idea, but it just might work... >Remember: just 'cause it's a Mac program doesn't mean you have to use the mouse >to do everything. They sold you the keyboard for a reason. >The mouse is a pointing device. Please don't use it for other things. >- Rich Holmes *** flame on *** Well, the smarminess of this answer might not have bugged me so much if it wasn't also so stupid. The technique I described is used in all kinds of games, including Dark Castle and Apache Strike. Keyboards simply don't give you the fine level of control needed, so you are right in that your idea *is* crazy, but unfortunately it *won't* work. The mouse is not a pointing device. The mouse is a device which reports relative movements. In *most* cases, it happens to be convenient to relate those relative movements to an absolute screen position. Too bad you can't make full use of it in other situations as well. How you can come to the conclusion that controlling movement on the screen in the way I described is like "using a screwdriver to pound in a nail" is beyond me. A better analogy is that it's like having a drill, and not being allowed to use it to as an electric screwdriver because "drills are only for making holes in things". *** flame off *** ==================================================================== Mark Smith Canon Research Centre Europe smith@canon.co.uk 19 Frederick Sanger Road ..ukc!uos-ee!canon!smith Guildford Surrey UK -------------------------------------------------------------------- "We always planned to ease ourselves into pure research anyway..." -- David Cronenberg, _Dead Ringers_
alistair@minster.york.ac.uk (06/07/90)
In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >In article <1990Jun5.091419.14219@portia.Stanford.EDU> canuck@portia.Stanford.EDU (William Stocker) writes: >>I'm writing a Mac program in THINK Pascal 3.0, and need to force the >>mouse to a particular screen location. I'm sure it's against Apple's >>guidelines (there's no SetMouse command I can find in Inside Mac I-V), >>but there's a good purpose for it -- trust me! I'm sure you have a good reason - so here is some code to do it. It's not original - I adapted it from some source someone else previously posted on the net procedure SetCursor (where: point); const { some dangerous low-memory-global equates } MBState = $172; { byte } MTemp = $828; { Low Level interrupt mouse location (point) } RawMouse = $82c; { unprocessed mouse location (point) } Mouse = $830; { processed mouse location (point) } CrsrNew = $8ce; { set <> 0 if mouse has moved (byte) } CrsrCouple = $8cf; { set = 0 if cursor not allowed to move (byte) } Couple = $ff; { value for CrsrCouple } Uncouple = $00; { value for CrsrCouple } var LowGlob: integer; LowMem: ptr; PointPtr: ^point; finalTicks: longint; 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; { SetCursor } ------------------------------------------------------------------ Alistair Edwards University of York, York, England YO1 5DD earn/bitnet: alistair@minster.york.ac.uk arpanet: alistair@minster.york.ac.uk internet: alistair%minster.york.ac.uk@nsfnet-relay.ac.uk usenet: ukc!minster!alistair
gchow@ipsa.reuter.com (george chow) (06/07/90)
In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. Well, I've been using SunView on a 386i for the last month or so and have gotten very used to the way that it relocates your pointer on top of the most safe response in any dialog box. After you respond, you are put right back where you were before the dialog box came up. It was very disconcerting in the beginning but after a few days, it becomes second nature to not `run' to any dialog box that pops up. (BTW, I use an SE mostly so that moving to any dialog box is not much of a problem but on the Sun/Apollo/Mac with big screens, it is semi-annoying to have to literally go so far to respond to any dialog box. > > << Brian >> >-- >| Brian S. Kendig \ Macintosh | Engineering, | bskendig | >| Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU >| Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | >... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/07/90)
In article <1990Jun7.090438.10194@canon.co.uk> smith@canon.co.uk (Mark Smith) writes: >rsholmes@rodan.acs.syr.edu (Rich Holmes) writes: >>In article <1990Jun6.083741.4740@canon.co.uk> smith@canon.co.uk (Mark Smith) writes >>>A perfect example of this is the old game Lode Runner, where >>>you indicate the direction of the man on the screen by pushing the mouse >>>in the appropriate direction. The man then keeps going in that direction >>>until the mouse is pushed in another direction. >>For a situation like this, why not use two keyboard keys to indicate left or >>right? In fact, why not left arrow and right arrow? >>Remember: just 'cause it's a Mac program doesn't mean you have to use the mouse >>to do everything. They sold you the keyboard for a reason. A very good point. However, the mouse is good for anything involving relative motion. I'm not familiar with Lode Runner; if the man on the screen has to be able to go at any speed in any direction (as opposed to stop/go in eight directions), then the mouse is the things to use. In that case you'd make the pointer visible, and have the man stop moving when the pointer is in a neutral place on the screen -- such as its center. Or, since the mouse in this case really doesn't have anything to do with the pointer, you might have a small window in a corner of the screen with a crosshairs to show you where the mouse is; when the crosshairs is centered, the man stops moving. Otherwise, if the man only moves horizontally, vertically, and diagonally, and only in one speed, why are you using the mouse? You mean that if I move the mouse way off to the left and then a tiny bit to the right, I get the same effect as if I had moved the mouse way off to the right? Weird. Ever play video games? Think about using a joystick for Missile Command, or paddle controllers for Pac-Man. Ugh! You need the right tools for the job. >>The mouse is a pointing device. Please don't use it for other things. >*** flame on *** Hold on, here, no flames! This is a serious subject. No one has the right answer. I'm looking for someone to persuade me that I'm wrong. >Well, the smarminess of this answer might not have bugged me so much if >it wasn't also so stupid. The technique I described is used in all kinds >of games, including Dark Castle and Apache Strike. Keyboards simply don't >give you the fine level of control needed, so you are right in that >your idea *is* crazy, but unfortunately it *won't* work. For Apache Strike (piloting a helicopter), it works very well. Ditto for Dark Castle (where you use the keyboard to move the on-screen character, who can only move in four directions at one speed, but use the mouse to control his aim for throwing stones). Note that in each game the pointer is invisible; you don't need it, and displaying it would only be a nuisance to the player. >The mouse is not a pointing device. The mouse is a device which reports >relative movements. In *most* cases, it happens to be convenient to >relate those relative movements to an absolute screen position. Too bad >you can't make full use of it in other situations as well. If you need to use the mouse as an analog input device for something, just make the pointer invisible. If you can't because you need the pointer, then you should probably rethink your application -- you're trying to have the mouse do too many things at once. >How you can come to the conclusion that controlling movement on the >screen in the way I described is like "using a screwdriver to pound in >a nail" is beyond me. A better analogy is that it's like having a >drill, and not being allowed to use it to as an electric screwdriver >because "drills are only for making holes in things". Interesting analogy... ;) The point here is that you should always use the best tool for the job. If the mouse is what you need, feel free to use it -- just remember to get rid of the pointer first by making it invisible so as not to confuse the user. On a similar note, people have brought up the point that, in a very complicated application, the program may need to move the pointer around itself to make life easier on the user. My reply to that is that two wrongs don't make a right -- the application should be made simpler (read: more intuitive). That's what the Macintosh stands for. For instance, look at System 7 (well, you can't *look* at it yet, but bear with me). The Finder will show you aliases: icons that aren't really files themselves, but that behave just like files, and actually point to files in other places. This could have turned out to be a pretty hairy deal -- how do you distinguish aliases? Do you put a box around them? Give them special icons? Add things to their names? Not distinguish them at all to prevent confusion? The final decision was to tell alias icons apart by displaying their names in italics. A simple, elegant solution, in my opinion, instead of cluttering up windows with extra pictures. You say the pointer will get lost in the jumble of information packed into your Great American Spreadsheet? Are you sure you're not displaying too much information at once, or perhaps you haven't displayed it as concisely as it might be? That's my point. And, to bring up one last point, I think that too much discussion about mouse techniques causes a person to use the word "point" entirely too much. Is it just me, or have I really overused the word? Sheesh. ;+) (A bit of pointed humor, there.) And to the guy who wondered if the thought police were onto him yet: A tall man wearing a trenchcoat will stop by your house later today. |-) << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
wiseman@tellabs.com (Jeff Wiseman) (06/08/90)
In article <3645@rodan.acs.syr.edu> rsholmes@rodan.acs.syr.edu (Rich Holmes) writes: >In article <1990Jun6.083741.4740@canon.co.uk> smith@canon.co.uk (Mark Smith) writes >>A perfect example of this is the old game Lode Runner, where >>you indicate the direction of the man on the screen by pushing the mouse >>in the appropriate direction. The man then keeps going in that direction >>until the mouse is pushed in another direction. > >Which is like using a screwdriver to pound in a nail. > >For a situation like this, why not use two keyboard keys to indicate left or >right? In fact, why not left arrow and right arrow? > Interesting point. But you know, for relative motion in games though, I really prefer the mouse. I rarely get my 3:00AM game cramps when using a mouse :-). >The mouse is a pointing device. Please don't use it for other things. True, but there are at least two ways to "point"--absolute (eg. "it's right THERE!") and relative (eg. "he went that'a way!"). I really like sometimes to have the mouse enable me to push something in the general direction that I want it to go (but then again, I DON't leave autocruise turned on ALL of the time,...hmm...) -- Jeff Wiseman: ....uunet!tellab5!wiseman OR wiseman@TELLABS.COM
isr@rodan.acs.syr.edu ( ISR group account) (06/08/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: > DON'T DO IT. It's *very* bad technique, and your application > won't run, besides. >[ ... ] >Tell me what, exactly, this `good purpose' is that you've thought up, >and I and millions of other Netters will help you come up with a more >proper way of doing it. Well, I guess that juist means that you and all the other millions of Netters don't ever want to use a graphics tablet or a digitizer, huh????? Or can you come up with a way to do that without setting the cursor postion??? That's just one example, because I had to do write a driver for one.. I'm sure there's plenty more if I thought about it.. -- Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ. InterNet: isr@rodan.acs.syr.edu Bitnet: SENSORY@SUNRISE
smith@canon.co.uk (Mark Smith) (06/08/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >If you need to use the mouse as an analog input device for something, >just make the pointer invisible. If you can't because you need the >pointer, then you should probably rethink your application -- you're >trying to have the mouse do too many things at once. Brian, I'm not sure that you understood the main reason I was whining. The problem is that when using the mouse as a relative motion device, the actual position of the pointer on the screen is still a problem, because if you move the mouse such that the pointer (whether visible or not) reaches the edge of the screen, you won't get any more mouse movements events in that direction. The only way around this problem is the admittedly inelegant method of throwing the pointer back to the middle of the screen, so that it never hits the edge. This is what you can't do *legally* on the Mac, and this (I assume) is why the pointer is visible in Lode Runner. This added challenge really doesn't enhance the game. BTW, it occurred to me after posting last time that Crystal Quest is probably the best example of precise non-linear control with the mouse. It's a very impressive use of a not very sophisticated input device, and I contend that it would be *impossible* with a keyboard. ==================================================================== Mark Smith Canon Research Centre Europe smith@canon.co.uk 19 Frederick Sanger Road ..ukc!uos-ee!canon!smith Guildford Surrey UK -------------------------------------------------------------------- "We always planned to ease ourselves into pure research anyway..." -- David Cronenberg, _Dead Ringers_
poorman@convex1.convex.com (Peter W. Poorman) (06/08/90)
gchow@ipsa.reuter.com (george chow) writes: >Well, I've been using SunView on a 386i for the last month or so and have gotten >very used to the way that it relocates your pointer on top of the most safe >response in any dialog box. After you respond, you are put right back where you >were before the dialog box came up. It was very disconcerting in the beginning >but after a few days, it becomes second nature to not `run' to any dialog box >that pops up. (BTW, I use an SE mostly so that moving to any dialog box is not >much of a problem but on the Sun/Apollo/Mac with big screens, it is >semi-annoying to have to literally go so far to respond to any dialog box. I actually wrote an INIT to do this on the Mac. I never got around to adding an icon and sending it to the world. What stopped me was trying to decide on the "right" behavior when modal dialogs are nested. (For example, the "Options" dialog within the Laserwriter "Page Setup" dialog.) Even worse, consider Microsoft Word's way of letting you move from one dialog to another by clicking a button. I couldn't decide when it was the right time to put the cursor back where it started. If there's an outcry I can get this out to the net FOR EXPERIMENTATION WITH USER INTERFACES only. I don't consider it well enough tested to turn loose on the world at large. --Pete Poorman poorman@convex.com
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/08/90)
In article <3668@rodan.acs.syr.edu> isr@rodan.acs.syr.edu (Michael S. Schechter - ISR group account) writes: >bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >> DON'T DO IT. It's *very* bad technique, and your application >> won't run, besides. >>Tell me what, exactly, this `good purpose' is that you've thought up, >>and I and millions of other Netters will help you come up with a more >>proper way of doing it. >Well, I guess that juist means that you and all the other millions >of Netters don't ever want to use a graphics tablet or a digitizer, >huh????? Huh? >Or can you come up with a way to do that without setting the cursor >postion??? A program doesn't have to know -- and, actually, shouldn't know -- what input device the user is using. Absolute devices such as graphics tablets typically have the interface in hardware; they move from place to place by simulating a corresponding sudden mouse movement. >That's just one example, because I had to do write a driver for one.. >I'm sure there's plenty more if I thought about it.. Your program doesn't have to move the pointer, the interface does. Since there are no system calls to move the pointer, you have to do it through hardware. << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
bskendig@phoenix.Princeton.EDU (Brian Kendig) (06/08/90)
In article <1990Jun7.133446.15665@ipsa.reuter.com> gchow@itcyyz.UUCP (george chow) writes: >In article <16995@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >>Tell me what, exactly, this `good purpose' is that you've thought up, >>and I and millions of other Netters will help you come up with a more >>proper way of doing it. >Well, I've been using SunView on a 386i for the last month or so and have gotten >very used to the way that it relocates your pointer on top of the most safe >response in any dialog box. After you respond, you are put right back where you >were before the dialog box came up. It was very disconcerting in the beginning >but after a few days, it becomes second nature to not `run' to any dialog box >that pops up. (BTW, I use an SE mostly so that moving to any dialog box is not >much of a problem but on the Sun/Apollo/Mac with big screens, it is >semi-annoying to have to literally go so far to respond to any dialog box. >> << Brian >> [ my .sig deleted ] First off, please don't quote someone's .sig without putting yours below it, in the interests of proper attribution. Secondly -- I can't get used to the pointer jumping all over the place on a Sun. I instinctively begin to move my pointer towards a dialog when it appears, but of course it's already there, so it usually zips off to some uncharted corner of the screen and (since the screen is large and monochrome) it takes me a few seconds to find it again. Not a terrible distraction, but about as annoying as dropping your pencil. Perhaps the answer isn't to have the mouse jump to a dialog, but instead to speed up the mouse tracking rate so you have faster access to all parts of the screen at all times. << Brian >> -- | Brian S. Kendig \ Macintosh | Engineering, | bskendig | | Computer Engineering |\ Thought | USS Enterprise | @phoenix.Princeton.EDU | Princeton University |_\ Police | -= NCC-1701-D =- | @PUCC.BITNET | ... s l o w l y, s l o w l y, w i t h t h e v e l o c i t y o f l o v e.
lsr@Apple.COM (Larry Rosenstein) (06/09/90)
In article <3668@rodan.acs.syr.edu> isr@rodan.acs.syr.edu ( ISR group account) writes: > Well, I guess that juist means that you and all the other millions > of Netters don't ever want to use a graphics tablet or a digitizer, In fact DTS has sample code to demonstrate how to write a tablet driver. (The code has a comment that says moving the pointer is meant for input device drivers only.) If people intend to move the pointer, then they should take a look at this; it's source code #17. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (06/09/90)
In article <1990Jun7.133446.15665@ipsa.reuter.com> gchow@ipsa.reuter.com (george chow) writes: > very used to the way that it relocates your pointer on top of the most safe > response in any dialog box. After you respond, you are put right back where You can achieve the same result by displaying the dialog box so that the safest option is under the pointer. This has the added advantage that the user is probably looking at the pointer already, so the dialog appears in the current area of interest. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
cbm@well.sf.ca.us (Chris Muir) (06/09/90)
Seeing as how my SetMouse() routine is being bandied about, with people
screaming that mouse moving is the devil's work, I thought I'd post a rebuttal.
This a very simple demo of a reason to move the mouse under program
control. It illustrates a control, called a "Numerical", that I first saw
it in a program by David Zicarelli. It appears in many music programs
(Opcode, Intelligent Music). I wanted to use it, so I cloned it. It gives
the feeling of directly manipulating a number. In a real program the user
would be able to type into it, too.
There are other good examples of moving the mouse, like pop-up palettes
that put the mouse on the current selection. Even Apple's pop-up menus
should move the mouse when a menu is close to the top or bottom of a
screen, and not moving it would result in the mouse being over a scroll
area. The idea of "warping" a palette to the current mouse position (which
I don't like any better than forcing the mouse to the palette) only works
if the edge of the screen doesn't get in the way. Games like Solarian II and
Crystal Quest are good examples of low level mouse control.
To sum up, I think that there are cases where moving the mouse under
program control is a good thing, not for the elusive "ease of use", but
rather, to create controls that couldn't exist otherwise.
-----
(This file must be converted with BinHex 4.0)
:#NjeE84PE5jcDA3!8dP8)90*9#%"!!!!'"X!!!!!X&C6593K!!%!!"JEFNaKG3%
!!!!!!!!!!J!06R9YCA*TBf&X4'9YEfpNG@aKFL"0B@0TER4[FfJ!!!!!!!!!!!"
J2X)!9dh)!'#SEJ0Z!3d!*J!"!!!!B$lF39"36$mr2cmK!D+@)ZbLPL5H!!!GX`!
!!!!!!"H9!!!!!,H@!!!!!!!!!!#5fJ!!"!J)J)10J"X1#Zcc"B%!,c!)"K`!`!#
!%3"-J"!!J'0!0!)P!QMJT%kE-R,5M!R$KNLC0Qmm!JJ#"3U6(cKrK"KS6X#LJ$4
YjY6*dbI"3L+6%K4P535lT"eQ5Ha4%8#8!'N)&#!54SiE&a)9)!PBJ"YCX`34!+#
B$)!b!-X)KJ#!$S#c!%)#N!!$3#$J`(q!rcNSH6,P5MBJA-)N'!&!@`K*!rm,3)&
J!%X!bJ`!!3,'CK!a2X[i21-c$BS"CDB1B#eT"!N!S!J%m5')2J!1)#%4mH8(J"F
*@U8,ibi-Zc$U`U!,Bbi-159i"$KD)`)'$`#3!%BC%B(%1S"2Tic-3RB'!Qm3Af"
m!!i+dJmJI%Z#H-2AH`$ZB!`-Q,"!`%$[%)J$a"4!#)&&&-Mm`im-[-`@R5Xcm2'
22adaJ!)!r`#3!-!C3LKa)3*ZJ"!KB"e"*pdD-%3BNJ$3,5##'L5Sb*%!B(!J4"S
9AXJ4L"#FJB#+IG&SJ)S8#A!MA`cJd&%!,lLK!!3i-#N&%"2!Gi#*dcQ!J*)%Z(L
'!42`%4)#$1$a`cr5L3'QQ!-P!+8!(YMfcaBbA%F!,#"FNBb#8J3a3a!!++!%$J*
%XJB'%N5jMhm!2-$!3!'BS3!)dA%c!8J(M$4$G*!!13$G!2Dd3F54$Y3*!!p#R"(
&R[b!m%3-H#L!"3!B`)'!+'#B38)-)0%!J!@L('#'"L'!T!8!-)6!4a&5*,&%3A!
%J+XC3i*N!@lHm!1!(L!N`4XA6rM!LcU%1"%0(,mP%!-`!S"3%VTJf)1P'LT3'J!
-3q"$'3J)3")*(3c!)NJC&SJ343M)8#B#)%*%)%*dUSL!#!L#4*-+!!b8"-SB*Ch
h"5JM1+(22lL!BS2)rp$#QhUK'1%#)ZEb*X%(kJ'R4!"R%"!H'!*Spm*B"-MhJFF
[!!$+$JZAj)39!B(J"J$Q2Fd!ZK"JJ!33%'5J"&J)R1%T@!VN6!S2B%!!#YN-E"e
ScUD3!#f!+$`Si&F(m&(JK"ISCBZa%p!X(9!@6lc!`a485$(#$f#R!SS)8MG-faQ
F!3%#&$"J)!2AXJ$KKJ6S6K(%Pe9(!dbm%%!`*5JZh)dH&)r`[I3rq!Ka5LTed0B
#%!V#m$3#dELMB!Y)+#JllEEM([XCUG!"`3G+!#!T##l`#FMYX%-21bbZ+0J'0RF
VA8869`54""9&,1d21c#!2@82Z-Z62J!)V)ml21ml3#$lrpMc2J2hidi2%Qli"ca
3-3S!`Jm9S8J9+JlaJqX`!"@+N!$#db3!3(qi!h&3`k!%R+#,IfJJ949d"bSBS4l
fR5ppqB0%!1@""'!%3PX#d0hj4)#!3F!3%N'!aJVaGm(SZ@0r@3##Ee!aL4#LSPa
H+!N4qR3&*hc2A9E`KcB!q!p[S!)6le1!r2lK2UjYNAjJX4m3m+FrX2"[M2j$3K[
m)3j8m)'+!bcJ'YAK4J-L!)&CT))3N@A')!ja%JTNS!-Kf-#1S#)4%J3!"GdJ43a
#3)-Fp)F53-K)EBb`K,M6"JVYS8)ZY[#&(G(G2l4"3aYf")Fkj#,qZ)'iIh!$L(X
NBJ8Y5BK#"Z#3!&5dBLDk9iFP"U'*hk1#h`#!#LZmVep2S`!$i&-!0M#JN!!+L+3
&U2!)-*!!i*JU")!biI-!CaBbD,VS"cqS#3B&&&)!(1`(2+Kj6&Jm63&X)%!L%B"
"HS,&!N&`KcCI!!*q4K)B6hJ(aSl*5b&m$`VMim``LrNq#Q566-cdjR@L'8j1N!$
cQQ"ak1k@f5L*aLHFJL#R1Dq$cR$DJCeFFfHJhN#!+HbZRKM%TciT`%prkX)I4JM
S3,R'bbSi`D"03+J`VD!J1k)#$L(3*`)3`)+N`Jm"+)J"2`#$!'FJ!3m!+!!9qF&
"I[L"Pe-S!K@Dm)3UK29e)T4#$jlQ!!%+)B$Zf'S$"e*)9D!#%#q)(PFlL!SX2)+
+q%L&(-!3%&4X9E#bbkZ#&"[B*a52LkP5V$a3S3C-jUq9pR"#+lC&66+LN!!IlS3
G'ab!3RLNdKim"!-$5YY*e1,ZKcj8+3,HB)#e`ZmIX-@Y5Z&CfhILYV5KGFFC2,"
@h!U`PI$!)!2b5DZDZLZF-0!T!eS3`+NH,a9c@&lcc)!K+1599T%8Kem,@B#Z8S#
DU*K#DAPCZ#!-B3R-JZ)rk,'rKhi5KMU%(rlS#aB-K*BHE!J)0YiR!C95J!dF5+3
%01K)jN,!Z9ePKA5KbF&pX++c%m`IB3%!"m!LpJb-0@SVPNFh`$!!,!%!M"P-i%M
-1YLj'+3!*-0*!je#J(f+"!-+[SZ"&rF6"!`'bb2['H0)bN#R&-#a"&+&AHdk$a&
"KTU2EES2-8ci1ZA9a6i3J&leQY'q,X6[l[El2[m'N!!Hp!(!J-&5i+GCi!dFF+N
LS`b"+6ph(l5iFU!iU!pDB&L4'Jj)K`-B@$P%0RVi%$'*FIH2%`Y%a5`@XS[eqH!
Iah6'r,#&MC@XBalEQFkAcQJkGB"N*6-jZmal-ThYc'Fek$R,qS"!P`R-hMkpeiP
0''Bp13J!2cmL&I3SD"+1))3J%)&CVi0(UQ`*4`lH!`[U8F)+i`N["pLbJDJ!!km
Ki&GH0V%)5CK#%S,k1Ri`i'N$8B!C8+#%0[`$'fm3!32D`*GhXd%$eKR!2i!aC[L
3!-N0+BEI''V,"e4m!RkbUqF(`,)!$Z,$&V4*1!m-6VfpiS-6Y-'HJU`!$#)!!!Q
!U$90JQ!&mCR2(fVdKb&3%B8+qU13!)$BY5l`!3kAUr%IkVJj1flZMP3XBYRA#F6
`#Q&CIr!b#%aJ&KA-@VkCbm$K,NMjC0f!#RqN3J+TJ%%UQ$'m2D!##NSMUMXik%S
KY1!Ijc$l2j34VG3Zq3`0"!`F8a'(j8N3YqGH#flIB!kJ#q6QeZ#J2DV$2(GMJ`d
M&8JN(8(0DdpFfcHPKPmhJ$YcA"9$QJ@!)2bk!Ya*Ji-"-!#[0kJ,!'JlLA9)JK2
'P`5NUjkSr*!!1!!!N3TJS!Gi#P*#p[JKU8)1)*)dS+CLqC%+(JcIf953!(db8T%
%p#!"#NM)`a+Y))980#%90q$P%ISNK#D8V`TU0iAD45(l!+4F(eF&6#TkJCi9)-%
IpRK"#q#IL[A-hakSQ)2mk9q"Qm1#[)@%!S9d!i@%!kK`#MH(#i8%"3$)!`&JEGF
""3FBGS[&0Gr&!"HMHaKM"Kj`D!U##[p`D2!cI+Q5+S*R$X[$-p'LI@+98diJ6#G
(43!`9qj"8XjQ!$HR#M*)GU,!1R6M$rq`08"),G'b!lLMJ`%dJ`jBJfXKH0K`Fkb
`Jae%"ci)"%!SJc6i6B*R#cIR#P,i$e*3K8$)5kSh2Nf3!!8ZU![eS!hTC(5P4e(
a83F8f(HRJ!VBF(["``p+F(EQF!BI"(Fm)(F"T!k*T9ICYQMrX!pJ3!'T3!Y!*iJ
iP`T`J)MlX$@*H!CL-BLmCJ&qYBGVG`Df`%Y&B!AP3`9-m!42m$Vbi$6`!`-3N!"
j+J!r!S!""1%")5%2D`%!qP3!!A!G#"!!AP!4!4"J"a!!TY!S!A!mV)J!,h!KQ3J
lUF!#4BG#4VGC1M!Q!8!08!-!&q)V@K!!Ea&JM!!!LL!lbpL-JC)+28!E4F0"!b!
'IN9B!D!+hm@-L*B+Xb#2R$!m*)!HXH!lq)#*M&9rmQJ)pFKB(#3!I-!kmNJ(M(@
1cTKbIT!!#L8JMelJJIJ!NHRS!8jf"J*K"0&#H@XRMkJ#BSLQNHB82Ik!#M[JC2,
)'EX$!YF4%2Z'#Ke4B[H`M&"&%!j`"KUa8E)a!0`&!2BJ1a!32IF!FVk4#Ml!MJ#
3!*!!P"#2!F%0pCL3!'`JPADaM)`$2p%#$$ML+8$!F4kRP,qK)k$R#&a36B@PN59
&6&KT#DR#PT39E8$JNCT(4I*35(#`J(IPJDZi1qKB8[+!Eaq!2rb`B9L`M##J)h+
!!H)!#J)!#!6a$jNR!ad"!$j!%,HK&Ri"!$+`M&eTNb`##&I3F4m(##+CGV26Mer
JLHG3QQ-CFam(GU9($QR*5d6`"+0BLP!8%&@T#`+!"*d)!'H`Beb6#L)3Pi"j)4L
!#Z,JC*,bQlrL9r@B#L'$HVPC"9"!"%&!2ZC$$r@BImZ)"#!"!36d!fF($(0&$d(
3$L3$BET!$a!JA9MSJ#aJ5a`d$fT!0G%$!,IM$raJ5`Y85!N!3IRN$r3`"1k*#b#
3!!d0@N(dd)"CK3UT3%9-iJ)!#U&-CPAZKJX)K*Y-G!@U4`6*pTX"3!I$Q60U3a,
Bq36Z439*8(+[S`iQ+J8T'K"f%*jc`)V6"4)+8&69K3Tai)(mi(qS-'+TjT-N#)J
!3!ESZ@rVfCl[q@1#*`j)CS6l4U6ek'&XB&PPP$qCGid5%55iq34$N!#+hNQ"4EQ
DH+JJC3TI@C!!Qdd84GV!MhKS35*i4j99Q,MM$hQ+#LM#TlQMNQ(U'($K2&A"!J"
J"-V(I-l(J(T93B(&U'FJUDPJ#jD&$aZ'!jp9U!2"%E'S)b'*1mU`B4c3UGBB%KE
K!"J6+2"6&8(#C$K3TYlR4'Ik1T,N#["M"J3!,aD`M$d!%Q``)AQ(!"-#QkG*KTj
6%b,U"-1NJ3M!Up@fM%SJV&eJQL#RV0cCV"kh&Xi!!,1#6Nb$-ES+!$U!#I"$"Xm
%0U"R$H6N!3bJUj)C%!J`"VeUHK!!2I"$"B!3#Kk`"J3!!e2e$rc#5q8@Vl0(%!`
`F2!LD!J!&J(a!$NM"EV+!!GT4TPRG[$"!!JlVaKMVr"#"!KVVZM+!'5J!KJd',S
3!'"!64@R")"`"K*`J86UM[-T8*1L9f@MV`c!Vk2`V`%lX!@,HX1%"1G`!"L!!V[
M!QE%!)H3!,!!`,#Q&a$ZJ![DiM`@H`"NaiPU#3$FS!5(B!B1m!)C8hVDi&F0kaB
)N!!Ta#N!8R!))-!%k!)$)'!%3'!'!J!+)9!&J+#S[Q!)C)!"+R!!$'!)!A'ZC3!
$6RZiQ&!'!D%('kB'IcX'JQX!KFZiC"!3@V#i**Zj!-!&B+!")-!!'dB(FIZC)'!
!N!"`#0)!"$!3#%D3!%2"!!1!!!EQ)!*-N!!XGKX%m4!3VSJL+q"Zq+!JFJ!!d"!
%-K!4!+!'q%#l)R!!NQ!)d"!-1&3'&(!'-33)Na!&B%!,F9X&%h-!r!S+)+!'U2!
#@RY681"A*J!%-&XHF5X#5`!#"B!kC-YV$Z"A),!!62!0'!!1"MZZqYSe#!!#3'!
%ZC+h(a$!X)1q2X!e9R!%#2#drLQm#J)#CmGl6##6K`X+rVS'!@%)-5!Krk!$QK!
#lJB21X!*lLG!,Cb4CdF2e-)[R6GI)J!%)i!%+f`G*NblB%!%eS-2'XF2Cm!,0B`
20G`U3%!(r`!'''#hBYX#)#%!e51m**!!`G!!$,%J$'3!$Ep,$X9l[-NE%-a,Zl"
`"'9`ZdJJ$FH`!NQJ)*!!F!6B+`1!B!4(!!2(`#mZX-"%1kl5"MpXJ!$(4!4!!!B
"be0p("$3'XJ$6!5e5`!$c-$mS$XB`bq"S%m1B*L8c!#@M-PAJcrqS*Llam$im&d
2KV'ET3A88mT#GS'C*`B9Yia$!*!!$GUJ[042I'(!)N!I##!#481k"!!"f6!&J@!
'qL!I432*3,$,m12,'(-'&M!HBX!!d4!-da!-%4!#a'c-*5(-fhc-GB!Zmm%Ac0c
,[m`ca)b*Xp!eq&!'!X#h8K"bi4`!id`!-P!d#%!#4D-!k#`)Ab),''!''BN!8b$
2Z+c-p``rqK`SKJ`"`6!&JX$0GC!!'K$VUJ&KD,'L"*hJ$,a'!L#8"c6j$dK!(`5
!"&GJ5b+J!eAN",8!'5"!EfcJ"*!!!'aCm!L#S`A-mJ4-"JSNF!8e,6MF539"X00
j-MN2N`$j,!9J8#VB)#NbS!%m)`3CX#S+XJ[*B!Bp0`UT-!Src30,9!4-304A!!S
P-$N#3J)0N!!I-S!"eG$59T%JJ68+m[%&Ddd$rS8&H[)2qM"*Cf"dm!!#V8,A''$
AX)!*HEhAUH,A)+!2k&(Ar[9@#S"$E@!!d!!%33!2SG3MIYddbI`#J%)!cXb-Am!
A4RXG**!!%HBR"-3`$"HL!ZCA"-K3$04!"%JJ",B0$-%!$B,3[kFL!JYF1jhpfD(
p!U0GdZF3!dpCHTc!ficJfmM-&jj0c[K-h+4ph-N0!(`!!J(!h-i0h0!Yh00Gh%D
,h,c'!Ycpf`FGhD!GhY90hUA(bG[p$3$3h,m0XfV!!8S3#'V!!)j-")(!DiRahld
8FU9R!IdYi2QY"JVJhlaQ!)jF%Li`Ni!K#i!`F#,!B8pC"l"`#0--#-&`0CBT"%"
`058K#abZ!@!KiPIMi9H$"%H3!*NZlJLcH`!Z,J0D@`HRE3)")!k))!k*B1*LJ!m
H$Jb(-"V#!!`Z-!!ZlJc!i1,5F!KPJ!#5)!KL3!!-AJF%!JEN8")%J98"J3KqJ3d
%!4*0`aHfP!UB,3PRMYQQX1B!S!YZEJeV(J$2G"d"J1B"F*pfMZG1-1GZX1B#))"
l$Jm,S)!NKHB#i!QqKqB"XHLB(4"b%a!@)HNL`3$FH1Q)%!"p!3"98!9TNBYYm4C
a!HPMN99S84B5-4GeF4GjX4HErKH"-4JQJ4)U`4+*m4*T"J#0m4L4%4L8)4%Vi"D
F$J!J)"'"d3m%B!4T`!CPN!!!9#!(BH!'Ff!'+0%@"%%!89!(D8!(9T%8Bc(U[Ck
)"&!%C,$Y"&!&EN!'p(%X!Y%#%M%!3e!(h$iVI$%%E`!()$d%C!%&B6!(G1#iieS
!3m$XA3%!3L!5!A!KCA![!4!$!5!$!6!$!8!$!9!$!@!$!A!$!4!P15!!-3!$(Km
$(Lm$(Mm$(Nm$(Pm$(Qm$(Rm$(NmS-G$ab5X!-L$b-N$b-Q$b-S$b-U$b-X$b-Z$
b-N!S-Y$a-`$b-b$b-d$b-f$b-i$b-k$b-m$b-q$b-d!S-p$a0!$b0#$b0%$b0'$
b0)$b0+$b0-$b01$b0%!S00$a03$b05$b08$b0@$b0B$b0D$b0F$b0H$b08!S0G$
a0J$b0L$b0N$b0Q$b0S$b0U$b0X$b0Z$b0N!S0Y$a0`$b0b$b0d$b0f$b0i$b0k$
b0m$b0q$b0d!S0p$aR#S!1#$b1%$b1'$b1)$b1+$b1-$b11$b1%!S10$a13$b15$
b18$b1@$b1B$b1D$b1F$b1H$b18!S1C!!!`2`mFS,!-8!!!Y`!8j3"Q9!"MXD!d1
r"L!J"8r3"(2J!L!`"@mJ"h+3!!FZX!"6d!BXJ4K6N!!'HP!',Z!!6b$[mf%',ih
VlFm&H)!K%1e1J1Q+Gh5!"6L00r$rB%,l!`&K`!k%J@8R"TLG#e!!"0!0'%!3J!$
IA`EFJ2B1hlN!#c!&aJ#dJ`-JJ!i`3$'3!!BJK`UF(2hZhk'r$fLkq*fr+`-+d!d
``*2J!2-!"*5!&0!#4K-'H!A53,Tl!hI!"6#!)S!(aJ$h)`-F%!ed"4H3!!#F!!1
dJ6+3!##S!S&`#JDH5K"rEb"%U%!8q!,2!!--Cc13!!em`IN3)X6!'k!$+V!0T%!
'D!C"J,Ul!eq"!kV"-5$qSKd84!0[J!e!`6!JlaMJ($#"JC!!$Cbra!$YA+!K,!1
Qb`fB"$'!%ZaJ'T!!!f9J$0!"0Z$q3%!3!!&f!#Ai`$*J"Xb!5NJ$CF!0Q+ik-!I
+32m$!BF3%kC#@!J(`S!6G!%03!Mi`#'!"P,#MQS#fNi1+-#BprXJeN!)#!B")5L
%!0!(6%mYJ!3*i#NJ``"J"$4%8!-8!8%+i$6b4a#m`&GM!J4"$CbTBj1,l)#i`@N
K`43J(5P!"3L#,fJ#a8B+%!4P`+d)JM@S9Ck1)iJ$`Q%iPX5N!``A3LPJL(r!Q5D
GXIX(!G(5533UpJq8a$CkGi""583!%i$`!!-(d#EiS0GGL!X3LbC6B!J)&q!BL33
5!3!Z!$33#B#!*&i!@S!5!80IZ!$%!1&*K![J$3"!'0J#(UFY2)#!J!&3`c`%!"@
!*p)LL4!A0!"22!)5)3$3!`$`!AML*,#*@q"#5+B5%"!b`#q!LU!JchQQJ+!"`0a
0"!'bVM$81X5J'0j!!3J#F!!1-,YNYqc+`,JVGh5J!&J"PK$p')!C#!0d`0DK"$Q
`rZB!!8J#EX!-[!&LK3!!:
--
__________________________________________________________________________
Chris Muir | "There is no language in our
cbm@well.sf.ca.us | lungs to tell the world just
{hplabs,pacbell,ucbvax,apple}!well!cbm | how we feel" - A. Partridgecbm@well.sf.ca.us (Chris Muir) (06/09/90)
In article <17078@phoenix.Princeton.EDU> bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: -A program doesn't have to know -- and, actually, shouldn't know -- -what input device the user is using. Absolute devices such as -graphics tablets typically have the interface in hardware; they move -from place to place by simulating a corresponding sudden mouse -movement. In fact, if an absolute device was going to position the pointer using "sudden mouse movement" to the mouse driver it would have to "home" the pointer (moving to a corner of the screen by outputting the screen width and screen height of pulses in the proper direction) every time the pen (or puck) touched down on the tablet. Not the way to do it. -Your program doesn't have to move the pointer, the interface does. -Since there are no system calls to move the pointer, you have to do it -through hardware. A ridiculous conclusion. Apple has even published a tablet driver in their sample code series that (shudder) moves the pointer by mucking with low memory globals. -- __________________________________________________________________________ Chris Muir | "There is no language in our cbm@well.sf.ca.us | lungs to tell the world just {hplabs,pacbell,ucbvax,apple}!well!cbm | how we feel" - A. Partridge
dan@b11.ingr.com (Dan Webb) (06/10/90)
in article <3668@rodan.acs.syr.edu>, isr@rodan.acs.syr.edu ( ISR group account) says: > > Well, I guess that juist means that you and all the other millions > of Netters don't ever want to use a graphics tablet or a digitizer, > huh????? > Or can you come up with a way to do that without setting the cursor > postion??? > That's just one example, because I had to do write a driver for one.. > I'm sure there's plenty more if I thought about it.. I think you've got it backwards. The tablet or mouse driver obviously should be able to move the cursor. IMHO, it should be the only software that moves the cursor. No one has mentioned this fact: It is impossible for an application to set the cursor position when an absolute device such as a tablet is being used because the tablet will immediately move it back. (Unless, of course, the tablet grabs the user's hand and jerks it toward the new location. :-) Dan Webb Intergraph ...!uunet!ingr!b11!dan
isr@rodan.acs.syr.edu ( ISR group account) (06/13/90)
bskendig@phoenix.Princeton.EDU (Brian Kendig) writes: >A program doesn't have to know -- and, actually, shouldn't know -- >what input device the user is using. Absolute devices such as >graphics tablets typically have the interface in hardware; they move >from place to place by simulating a corresponding sudden mouse >movement. Ah, but this particular digitizer communicated via the serial port and gave it's output in the form +/-NNN.NNN +/-NNN.NNNB it would have been quite a project to build a hardware interface for it as opposed to simply writing a D/A that would accept the serial input and control the cursor. And no, we could not buy an off-the-shelf tablet - it had to be a sonic digitizer. In this case, at that time, moving the mouse pointer was the only way (short of building the above mentioned inerface) to accomplish what we needed. In any case, this discussion started out (I believe) by someone saying that Apple SHOULD have provided the capability - I say he/she was right - there should be system calls, perhaps with strong warnings about how it doesn't follow HI guidelines, but the capability should be there. -- Mike Schechter, Computer Engineer,Institute Sensory Research, Syracuse Univ. InterNet: isr@rodan.acs.syr.edu Bitnet: SENSORY@SUNRISE