mentat@auscso.UUCP (Robert Dorsett) (01/25/88)
A few weeks ago, I posted a request for tips on how to set the screen cursor
position, totally under software control, then reassociating that position with
the mouse. Eric Eide (u-eeide%ug.utah.edu@utah-cs.UUCP) kindly helped fill
in some information that Apple, for some reason, has chosen to leave out of
all its documentation (without even providing a ROM call to work around the
lack of low-memory information). Before I start receiving flames: yes, I
know it's a bad idea to screw around with low memory, but one has no choice.
SO, here's a picture of relevant memory (courtesy Mr. Eide):
Variable MTemp, point (longword), $828. You can get at it from Lightspeed
C by defining the variable
extern point mtemp : 0x828;
somewhere in your program. You can use the same syntax for all the variables
I discuss. I'm not really sure what the variable does; it seems like an inter-
mediate counter to take care of non-sequential movements. There are quite a few
data structures to handle cursor position, so this may not be correct.
Variable RawMouse, point (longword), $82C. This is apparently the raw, input
mouse position before processing by the vertical retrace interrupt manager (?).
Variable CrsrBusy, boolean (byte), $8CD. Prevents the mouse handler routines
from doing anything to the cursor while we're messing around with it.
I initially tried the sequence (given a point I wished to move to):
crsrbusy=TRUE;
mtemp=mypoint;
rawmouse=mypoint;
crsrbusy=FALSE;
which didn't work. That basically simulates "ObscureCursor()", i.e., it'll hide
the cursor until you move the mouse, then it'll jump to the desired location
on the screen.
Mr. Eide later pointed out that for total software control, using the "temp-
orary" variables", one needs another variable, CrsrNew. This can then
be inserted right before the last crsrbusy assignment to inform the system
that the cursor needs updating. The variable is located at $8CE, and is a
boolean (byte). I have not tried this, though.
In the meantime, I searched for other ways, since I had to have absolute soft-
ware control of cursor position. In a 1985 variable listing (fortunately, I
don't throw things away), I discovered variable Mouse, a point (longword), at
location $830. This is the "Mouse" position, such as "GetMouse()" might
return.
I found that I was able to change the cursor position with simply
mouse=mypoint;
but I still change the cursor busy state to be safe. I haven't had a crash
since playing with this stuff.
Mild flame at Apple: most of the above is relatively undocumented. It is not
in Inside Macintosh or any of the Tech Notes. Mr. Eide got his information
from a book by Scott Knaster. I managed to fill in the rest from the afore-
mentioned variable list. I can sympathize with the rationale in not wanting
people to mess with cursor position, but to HIDE the information indicates a
certain lack of trust in the judgement of developers (whether professional or
amateur). The notion of not relocating mouse position isn't particularly deep
or difficult to understand, and I'd wager that anyone who has experienced a
cursor jump (such as during a disk access) can testify to the faint feeling of
disorientation it causes. I doubt that you'd find anyone who will change
cursor position haphazardly (I am only interested because, when I call hide-
cursor, I want the cursor to be where it disappeared when I call showcursor
again). Your omission cost me a lot of time tracking this down.
Incidentally, the above variables seem to work on the SE, as well as the
Plus. They probably work on older Mac's as well, but I haven't tried.
On to part two of this post.
The new Macs (Plus and beyond), as we all know, save several levels of mouse
scaling in Parameter RAM. The location and nature of this scaling is complete-
ly undocumented in Inside Mac IV, and is disguised by a red herring
from the documentation for the old ROM's (crsrthresh) that is completely
unused by modern systems.
I have not been able to get scaling to work (and would appreciate any help from
people who know how). All I've been able to determine is that the spvolctl
field (a variable byte at location $208) has been redefined under the 128K
and 256K ROM's to now include the scaling threshhold that is actually used.
Those of you with interest may wish to mark page II-372 of Inside Mac to in-
dicate that the bits 11-15 of the VolClik field (spvolctl is the high-order
byte of VolClik) are now used for scaling. Problem is, the Control Panel only
sets bits 11, 12, 13, and 14. I don't know if bit 15 is reserved, or whether
it's to indicate a level of sensitivity over and above "maximum" (it might be a
good idea on very large screens). At any rate, one can determine the mouse sen-
sitivity after clearing bits 8-10, the sound level. My problem: if I write in
new values, nothing happens. The cursor sensitivity goes to maximum. Anyone
who has clues as to why this is so, please contact me.
And a last flame at Apple: again, the tendency in "developer" support over the
last six months or so has been to assume we don't know what we're doing. I
am well aware of the flames that the Mac is difficult to program, but I don't
feel that an undue proportion of resources should be dedicated to cranking out
tech notes noting the difference between such elementary concepts as a handle
and a point. Instead, PLEASE try to keep the information as useful and
professional as possible. If you can't publish information, don't publish.
It's not your responsibility to *teach* people how to program, yet there were
at least three tech notes last year which attempted to do precisely that.
--
Robert Dorsett {allegra,ihnp4}!ut-sally!ut-emx!
walt.cc.utexas.edu!mentat
University of Texas at Austin {allegra, ihnp4}!ut-sally!ut-emx!auscso!mentat steele@unc.cs.unc.edu (Oliver Steele) (01/27/88)
[dgold@apple.UUCP (David Goldsmith) writes that setting the mouse position
directly, and using undocumented low memory globals in general, are poor
ideas and are likely to cause a program to break in the future.]
I agree with your general point about keeping as many globals as possible
verboten, especially now that multitasking approaches, but how does Apple
recommend for people writing paint programs, for instance, to show that a
grid or other constraining factor is in effect? I notice that there's
already some inconsistency -- constraining to a grid, in many programs,
makes the mouse street-wise*; but constraining tool motion to an axis
doesn't constrain the cursor to that axis. I also notice that HyperCard
plays with exactly these low-memory globals; is this OK because HyperCard
is system software (1/2:-)?
----------------------------------------------------------------------------
Oliver Steele ...!{decvax,ihnp4}!mcnc!unc!steele
steele@cs.unc.edu
*Taxi-cab geometry, of course.lsr@apple.UUCP (Larry Rosenstein) (01/28/88)
In article <888@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: > >... how does Apple recommend for people writing paint programs, for >instance, to show that a grid or other constraining factor is in effect? I >notice that there's already some inconsistency -- constraining to a grid, >in many programs, makes the mouse street-wise*; but constraining tool >motion to an axis doesn't constrain the cursor to that axis. I think the philosophy should be that the user is in control of the mouse and the cursor. Therefore, the user can move the cursor anywhere on the screen (even between grid points). If the program has some sort of gridding on, then it acts as a constraint on the object being manipulated and not on the cursor position. In this case, moving the mouse a tiny bit will move the cursor, but won't make any change on the screen. I don't know why the inconsistency happened. It is possible that the programmers considered constraining the cursor to 1 axis to be too severe. (I think some users would consider such a constraint as a sign that the mouse was broken!) -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc}!apple!lsr CSNET: lsr@Apple.com
jcc@ut-emx.UUCP (Chris Cooley) (01/30/88)
In article <338@metasoft.UUCP>, alan@metasoft.UUCP (Alan Epstein) writes: > In article <7272@apple.UUCP>, dgold@apple.UUCP (David Goldsmith) writes: > > Changing the mouse position directly is an operation we do not support. > > we are aware that apple does not support move movements. the question is > why not? i'm not ashamed to admit that we 'broke the rules' in > implementing PutMouse(), because we expected the interface to > support us in this. fortunately since the 512K it has NOT broken. I don't wonder what would happen if Microsoft Corp. decided that they needed a PutMouse(). I can see System 4.3 coming out REAL soon afterwards! Just poking fun, --chris /---------------------------------v------------------------------\ ( J. Chris Cooley |[mailpaths under construction] ) (( Univ. of Texas Comp. Center | jcc@ut-emx.UUCP )) (( Austin, TX 78712 | jcc@emx.cc.utexas.edu )) ( 512/471-3241 x417 | ) \---------------------------------^------------------------------/ \Disclaimer: You think THEY agree with THESE opinions? Hah!/ \--------------------------------------------------------/
jmunkki@santra.UUCP (Juri Munkki) (01/31/88)
In article <7279@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <888@thorin.cs.unc.edu> steele@unc.UUCP (Oliver Steele) writes: >>... how does Apple recommend for people writing paint programs, for >>instance, to show that a grid or other constraining factor is in effect? >I think the philosophy should be that the user is in control of the mouse >and the cursor. Therefore, the user can move the cursor anywhere on the >screen (even between grid points). Right! It's a very good rule not to constrain the mouse. The only place I would allow cursor reposisitioning is in games (as in MacLanding) that will break anyway sooner or later. :-) (Game programmers think they can forget all rules of compatibility just for the sake of speed...they never think of making speed an option and writing stuff twice: an optimized version and a compatible version...the future machines will be faster so the optimizing might be wasted on them anyway.) >If the program has some sort of gridding on, then it acts as a constraint on >the object being manipulated and not on the cursor position. In this case, >moving the mouse a tiny bit will move the cursor, but won't make any change >on the screen. Macintosh programmer don't seem to like large crosshairs. I'd like to see more draw and paint programs that can display window-sized crosshairs. The cursor can still be visible, but the crosshairs will show how the grid constrains movement. As far as I can see large crosshairs aren't mentioned in apple documentation, but then again they aren't forbidden. Is there any reason they shouldn't be used? (I remember seeing them somewhere...MacDraft perhaps?) Juri Munkki jmunkki@santra.hut.fi jmunkki@fingate.bitnet