Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!sunybcs!rutgers!mcnc!kk From: kk@mcnc.org (Krzysztof Kozminski) Newsgroups: comp.sys.mac Subject: There *ARE* uses for forcing the mouse to a location (non-games). Message-ID: <2285@speedy.mcnc.org> Date: 6 Jun 90 23:33:53 GMT References: <1990Jun5.091419.14219@portia.Stanford.EDU> <16995@phoenix.Princeton.EDU> Reply-To: kk@mcnc.org.UUCP (Krzysztof Kozminski) Organization: MCNC; RTP, NC Lines: 75 In the beginning a suggestion to Apple: 1) Let the user choose in the Control Panel whether she/he wants to allow a 'jumping mouse pointer'. There's lotsa space there to fit one checkbox that is needed. 2) Provide a flag in SysEnvirons that lets the program know the status of this bit, so that the program can use it for the convenience of the user. 3) Provide this sorely missing routine for setting the mouse position. Something like SetMouse(x,y), returning TRUE if mouse was set, or FALSE if it was not set. (e.g, if the user has turned the 'jumpy mouse' off, or the position was off-screen or something like this). 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. > > 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. I am not the original poster, but coming up with a good purpose seems to be a trifle (hey, I am so stuffed with painkillers right now that I can come up with ANY idea for anything :-) Purpose 1. Imagine running MacDraw on a large screen (1200x1000 pixels or more), editing some stuff in the lower right corner. You want to change a tool and continue drawing in the lower right corner. You have to move the mouse all the way to the palette, select a tool, and move it all the way back. Kinda trouble, especially on a cluttered desk with all 2 inches to mouse about without bumping your coke can off the desk... Solution accordingly to the guidelines: you gotta roll this mouse. Or dig up this reference card and find out which option-command-control- capslock-shift combination selects the tool you want (in case your program was produced by a certain company that considers shift-option-H to be a perfect mnemonic for changing the text style to subscript :-) Solution that comes immediately to anybody whose perspective has not been limited by a puny 512x340 screen and/or by The Gospel from Apple (or whose perspective has been broadened by a substantial dose of opiates after surgery :-) - press, say, key: pointer moves to the palette containing controls <-> CTRL key - quite easy to remember. - select the tool you want, - release the : pointer moves to the area where you were doing your things Purpose 2: You are editing elaborate widgets on your elaborate multi-screen setup, double-click on a widget to open a dialog, and thanx to the ossified guidelines gotta move this mouse to the dialog, then back to your widget ... Opening the dialog in the vicinity of the widget would obscure the widget, hence is no good... Solution: if looking at the widget is useful while manipulating the dialog, open the dialog on another screen, jump the pointer there, return the pointer to the widget after dismissing the dialog. I would be very interested in hearing any suggestions for handling such situations that are both convenient and consistent with the guidelines (then I'll swallow another Percocet and generate more 'good purposes'). Actually, here's the best reason: LOTS of programs using X-windows move the mouse. How are you going to run X-windows on a Mac without this capability? KK -- Kris Kozminski kk@mcnc.org "The party was a masquerade; the guests were all wearing their faces."