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 reasons not to deleted] >| Brian S. Kendig \ Macintosh | Engineering, | bskendig | From page 84 of 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 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} Note that it uses undocumented low memory globals. P.S. This is the second posting of this reply I think. The Followup line was to comp.sys.mac. Oops! -- ___________________________________________________________ Matthew Mora SRI International mxmora@unix.sri.com ___________________________________________________________
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>
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
ts@cup.portal.com (Tim W Smith) (06/08/90)
In anticipation of virtual memory, I offer the following description of how to set the mouse to any point on the screen. Step 1. Place mouse at 0,0. Turn on the journalling driver. Move mouse to 0,1. Turn off the journalling driver. Step 2. Similar to step 1, but move to 0,2. ... (do this for each pair of pixels) Now, to move the mouse from any location to any other location, use the journalling mechanism to play back the appropriate movement. :-) Seriously, I wonder if there is some way to get the journalling stuff to do this for you. This may be a safer way then directly mucking with low memory globals. Tim Smith
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 <30614@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >In anticipation of virtual memory, I offer the following description >of how to set the mouse to any point on the screen. > > ... > >Now, to move the mouse from any location to any other location, use the >journalling mechanism to play back the appropriate movement. :-) Yeah, you would need about four gig of VM to do this for a Mac II screen... ;-) >Seriously, I wonder if there is some way to get the journalling stuff >to do this for you. This may be a safer way then directly mucking with >low memory globals. Didn't Apple say something a while back in some Tech Note that the journalling capability of the Event Manager really shouldn't be used, and that even the Inside Tour no longer makes use of 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.
rang@cs.wisc.edu (Anton Rang) (06/08/90)
In article <30614@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Now, to move the mouse from any location to any other location, use the >journalling mechanism to play back the appropriate movement. :-) <grin> It might work, but would probably be too slow. I seem to recall reading, too, that MacroMaker "owns" the journalling driver, and programs are no longer supposed to use it. >This may be a safer way then directly mucking with low memory globals. It might, but the globals seem to work for now. Unless Apple gives in and provides SetMouse(), I think this mechanism is as good as any other. (It will probably work until the advent of protected memory, anyway.) Just my thoughts.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
stoms@castor.ncgia.ucsb.edu (David Stoms) (06/12/90)
In article <30614@cup.portal.com> ts@cup.portal.com (Tim W Smith) writes: >Seriously, I wonder if there is some way to get the journalling stuff >to do this for you. This may be a safer way then directly mucking with >low memory globals. What journalling stuff? That small section in the Event Mgr was discontinued years ago. AppleEvents maybe, but journalling, no chance! Josh.