sirkm@ssyx.ucsc.edu (Greg Anderson) (12/29/89)
TN #117 says to look at the QuickDraw variable screenbits.bounds to
find the size of the screen, but on my Mac IIx, this rectangle is
always (0,0,0,0) when MultiFinder is installed (color or b&w).
The Q&A stack says to "look at all gDevices", taking the union of each
screen rectangle to find the total region that makes up the screen,
but I'm somewhat unclear on how to do this.
First question: what _is_ a gDevice? Is there one & only one gDevice
per monitor (/other display device) hooked up to the Mac, or might there
be multiple devices referencing a single monitor? If the later, why?
The reason I wish to know the size of the screen is simply to center my
dialogs on the screen. Given this purpose, should I just look at one
gDevice (namely, the one returned by GetGDevice)? Once I have this handle,
how should I determine the screen bounds? Get the PixMap from
(*gDev)->gdPMap and then look at pixMap.bounds?
I'm working from the Beta draft of IM V (unfortunately).
___\ /___ Greg Anderson ___\ /___
\ \ / / Social Sciences Computing \ \ / /
\ /\/\ / University of California, Santa Cruz \ /\/\ /
\/ \/ sirkm@ssyx.ucsc.edu \/ \/tim@hoptoad.uucp (Tim Maroney) (12/30/89)
In article <10139@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >TN #117 says to look at the QuickDraw variable screenbits.bounds to >find the size of the screen, but on my Mac IIx, this rectangle is >always (0,0,0,0) when MultiFinder is installed (color or b&w). Uh, I really don't think so. Check again. >The Q&A stack says to "look at all gDevices", taking the union of each >screen rectangle to find the total region that makes up the screen, >but I'm somewhat unclear on how to do this. The way to do it for dragging is to call GetGrayRgn() (IM vV) and use its bounding box. But this isn't what you're doing.... >The reason I wish to know the size of the screen is simply to center my >dialogs on the screen. Given this purpose, should I just look at one >gDevice (namely, the one returned by GetGDevice)? Once I have this handle, >how should I determine the screen bounds? Get the PixMap from >(*gDev)->gdPMap and then look at pixMap.bounds? You probably don't want to center dialogs across all monitors. You want to center them on the main screen. So use screenBits.bounds to get the rectangle of the main screen. It's *not* an empty rectangle on a properly functioning Macintosh. The Window Manager chapter of Inside Mac volume V continues to endorse its use. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "But don't you see, the color of wine in a crystal glass can be spiritual. The look in a face, the music of a violin. A Paris theater can be infused with the spiritual for all its solidity." -- Lestat, THE VAMPIRE LESTAT, Anne Rice
oster@dewey.soe.berkeley.edu (David Phillip Oster) (12/30/89)
In article <10139@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >TN #117 says to look at the QuickDraw variable screenbits.bounds to >find the size of the screen, but on my Mac IIx, this rectangle is >always (0,0,0,0) when MultiFinder is installed (color or b&w). Tim Maroney is right, it should return the bounding rectangle of the CRT that has the menu bar. It always has for me. >First question: what _is_ a gDevice? Is there one & only one gDevice >per monitor (/other display device) hooked up to the Mac, or might there >be multiple devices referencing a single monitor? If the later, why? There should only be one at a time. Some video boards change the number of pixels they display depending on what mode they are in: i.e, they might be 640x480 in 8-bit per pixel mode, by 1024x1204 withe one bit per pixel. In addition, since graphic devices hold the inverse color table data structures (used for color matching when you do a CopyBits of a pixmap with one color table to a pixmap with a different table) there may be graphic devices that aren't connected to screens. >The reason I wish to know the size of the screen is simply to center my >dialogs on the screen. Given this purpose, should I just look at one >gDevice (namely, the one returned by GetGDevice)? Once I have this handle, >how should I determine the screen bounds? Get the PixMap from >(*gDev)->gdPMap and then look at pixMap.bounds? use screenBits.bounds. Here _is_ a use for gDevices: I redefine the zoom box, so that windows zoom to the full size of the CRT they are on, rather than Apple's default. There is nothing more annoying than working with a two-monitor system, clicking on the zoom box of a window, and have it leap to the other, smaller montior. Here is a code fragment: /* GetBiggestZoom - set r to the dimensions of the largest extern SysEnvRec world; biggdh = NIL; if(world.hasColorQD){ for(gdh = GetDeviceList(); gdh != NIL; gdh = GetNextDevice(gdh)){ if(TestDeviceAttribute(gdh, screenDevice) && TestDeviceAttribute(gdh, scrnActive)){ if(biggdh == NIL || (**gdh).gdRect.bottom - (**gdh).gdRect.top > (**biggdh).gdRect.bottom - (**biggdh).gdRect.top){ biggdh = gdh; } } } } if(biggdh == NIL){ *r = screenBits.bounds; r->top += GetMBarHeight(); }else{ *r = (**biggdh).gdRect; if(TestDeviceAttribute(biggdh, mainScrn)){ r->top += GetMBarHeight(); } } } > The mac is a detour in the inevitable march of mediocre computers. > drs@bnlux0.bnl.gov (David R. Stampf) --- David Phillip Oster -master of the ad hoc odd hack. Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
willcox@urbana.mcd.mot.com (David A Willcox) (01/03/90)
In article <9429@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <10139@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >>TN #117 says to look at the QuickDraw variable screenbits.bounds to >>find the size of the screen, but on my Mac IIx, this rectangle is >>always (0,0,0,0) when MultiFinder is installed (color or b&w). > >Uh, I really don't think so. Check again. This sounds a bit like what happened when I tried to use screenBits from within an XCMD. The problem, of course, was that I hadn't called InitGraf() (I hope that's the right name) from within my XCMD, and I was seeing a local copy of screenBits that had not been initialized. (I'm using Think C 3.0.) I tried calling InitGraf() within my XCMD, and that gave me valid values for screenBits, but things rapidly went to hell on return to HyperCard, since HyperCard's quickdraw globals didn't work any more. (Obvious, in hindsight.) I managed to do what I wanted to do (center a dialog in the window) by looking at the grafport that was active on entry to the XCMD. It worked, but I worry that it might break under some conditions. Can anyone tell me, is there a better way to get at global variables such as screenBits from within an XCMD? David A. Willcox Motorola Urbana Design Center UUCP: ...!uiucuxc!udc!willcox 1101 E. University Ave. INET: willcox@urbana.mcd.mot.com Urbana, IL 61801 FONE: 217-384-8534
sirkm@ssyx.ucsc.edu (Greg Anderson) (01/04/90)
In article <1102@urbana.mcd.mot.com> willcox@urbana.mcd.mot.com (David A Willcox) writes: [quoted references to invalid screenbits.bounds deleted] >This sounds a bit like what happened when I tried to use screenBits >from within an XCMD. The problem, of course, was that I hadn't called >InitGraf() (I hope that's the right name) from within my XCMD, and I >was seeing a local copy of screenBits that had not been initialized. I know it's illegal to call InitGraf() from within XCMD's, but can I call it from within a DA? It seems like I would have the same problems you experienced. If I cannot call InitGraf() from within my DA, then how can I find the size of the screen? screenbits.bounds can be used under UniFinder, and I can look at the main screen's gDevice on a system with color quickdraw, but that still leaves me stuck in Multifinder systems that don't have color quickdraw. >Can anyone tell me, is there a better way to get at global variables >such as screenBits from within an XCMD? Sort of -- make callbacks to HyperCard. This won't always get you what you want, but it can often be very helpful. For example, I have an XCMD that centers its dialog on the HyperCard window by making a callback that asks HyperCard where its window is. Under HyperCard, I find it much nicer to have dialogs centered on the HyperCard window rather than the whole screen; that way they look like they're part of HyperCard. Dialogs that center on the whole screen look like system messages. If you'd like, I could send you the source. ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
tim@hoptoad.uucp (Tim Maroney) (01/04/90)
In article <10139@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >>>TN #117 says to look at the QuickDraw variable screenbits.bounds to >>>find the size of the screen, but on my Mac IIx, this rectangle is >>>always (0,0,0,0) when MultiFinder is installed (color or b&w). In article <9429@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>Uh, I really don't think so. Check again. In article <1102@urbana.mcd.mot.com> willcox@urbana.mcd.mot.com (David A Willcox) writes: >This sounds a bit like what happened when I tried to use screenBits >from within an XCMD. The problem, of course, was that I hadn't called >InitGraf() (I hope that's the right name) from within my XCMD, and I >was seeing a local copy of screenBits that had not been initialized. >(I'm using Think C 3.0.) When I first read this, I though, "Of course!" But now, I'm not sure this makes sense. The XCMD should be called using HyperCard's A5, and its QD globals are initialized already. Maybe the problem is that LSC has a bug that looks for the QD globals off A4 if you are linking a code resource? That wouldn't be too surprising. But the LSC code resource glue doesn't mess about with the caller's A5, which should remain constant throughout. >I tried calling InitGraf() within my XCMD, and that gave me valid >values for screenBits, but things rapidly went to hell on return to >HyperCard, since HyperCard's quickdraw globals didn't work any more. >(Obvious, in hindsight.) Sort of. This seems to be compatible with the A4-bug hypothesis, assuming that the code generated was using offsets from A4 and you passed a pointer to thePort which was also A4-relative. >Can anyone tell me, is there a better way to get at global variables >such as screenBits from within an XCMD? Tell me, did you try the ugly way of accessing QD globals from assembly language, from IM I-163? I bet it would work. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Gorbachev is returning to the heritage of the great Lenin" - Ronald Reagan
oster@dewey.soe.berkeley.edu (David Phillip Oster) (01/05/90)
In article <10164@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >I know it's illegal to call InitGraf() from within XCMD's, but can I >call it from within a DA? No, you can't call it from a DA either. >If I cannot call InitGraf() from within my DA, then how can I find the >size of the screen? Here is how you access the quickdraw globals from a non-application, assuming that _some_ application has set them up by calling InitGraf: (A safe assumption for D.A.s, CDEFs, MDEFs, WDEFs, CDEVs, & FKEYs) /* QuickDraw - access to globals from a code resource brought to you by David Phillip Oster (oster@well.sf.ca.us or oster@dewey.soe.berkeley.edu) You may use this as you see fit. */ typedef struct QuickDraw { LongInt randSeed; BitMap screenBits; Cursor arrow; Pattern dkGray; Pattern ltgray; Pattern gray; Pattern black; Pattern white; GrafPtr thePort; } QuickDraw; /* DisableSelf - this is from a CDEF I wrote, it dims the control. */ DisableSelf(ch)ControlHandle ch;{ QuickDraw *qd; Rect r; qd = (QuickDraw *) ( *(Byte **) CurrentA5 - (sizeof(QuickDraw) - sizeof(GrafPtr)) ); r = (**ch).contrlRect; PenMode(patBic); PenPat(qd->gray); /* <-- Note, a QD global! */ PaintRect(&r); PenNormal(); } --- David Phillip Oster -- No, I come from Boston. I just work Arpa: oster@dewey.soe.berkeley.edu -- in cyberspace. Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
tim@hoptoad.uucp (Tim Maroney) (01/05/90)
In article <1102@urbana.mcd.mot.com> willcox@urbana.mcd.mot.com (David A Willcox) writes: >>This sounds a bit like what happened when I tried to use screenBits >>from within an XCMD. The problem, of course, was that I hadn't called >>InitGraf() (I hope that's the right name) from within my XCMD, and I >>was seeing a local copy of screenBits that had not been initialized. In article <10164@saturn.ucsc.edu> sirkm@ssyx.ucsc.edu (Greg Anderson) writes: >I know it's illegal to call InitGraf() from within XCMD's, but can I >call it from within a DA? It seems like I would have the same problems >you experienced. It sounds like your problem is with THINK C. If you'll look on page 78 of the THINK C 3.0 Manual, you'll find that this issue is explicitly addressed. "If you access these globals from a driver, you'll find that they aren't the real QuickDraw globals but simply the driver's own globals that QuickDraw knows ntohing about. You can access the real QuickDraw globals from a driver by observing that 0(A5) holds the address of the last of the QuickDraw globals, thePort. The remaining QuickDraw globals are at descending addresses from thePort; refer to Inside Macintosh I, Chapter 6, 'QuickDraw', for more information." This is what I told you in my last message, but perhaps you'll take it more seriously from the compiler manual. You haven't been looking at screenBits.bounds at all.... >If I cannot call InitGraf() from within my DA, then how can I find the >size of the screen? screenbits.bounds can be used under UniFinder, and >I can look at the main screen's gDevice on a system with color quickdraw, >but that still leaves me stuck in Multifinder systems that don't have >color quickdraw. Use inline assembly language in THINK C to access the QD globals from non-applications. Use screenBits.bounds to find the size of the screen. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "I wouldn't work for Dukakis if my life depended on it. I've worked for Greeks and I know just how filthy and stinking they can be." -- Caller, KGO-AM, 8 Nov 88
jmunkki@kampi.hut.fi (Juri Munkki) (01/06/90)
Why would anyone want to access QD globals from a DA/XCMD? The only global that might be relatively useful is randSeed. To find out the size of the main screen, call OpenPort to open a dummy grafport. No need to go peeking at application/QD globals. (Unless you really want to.) _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
tim@hoptoad.uucp (Tim Maroney) (01/07/90)
In article <1990Jan5.234652.4485@santra.uucp> jmunkki@kampi.hut.fi (Juri Munkki) writes: >Why would anyone want to access QD globals from a DA/XCMD? The only >global that might be relatively useful is randSeed. To find out the >size of the main screen, call OpenPort to open a dummy grafport. No >need to go peeking at application/QD globals. (Unless you really want >to.) Nope. The OpenPort strategy doesn't work on color systems, at least not in the simple way you seem to be suggesting. If you just look at port.portBits.bounds, you'll be looking at something weird (a handle followed by two integers) on color systems. You can do it (code is below), but using screenBits.bounds is easier. It also consumes much less stack space, less heap space, and less processing overhead in OpenPort and ClosePort. if ((port->portBits.rowBytes & 0x8000) == 0) screen = port->portBits.bounds; else { PixMapHandle pm = ((CGrafPtr) port)->portPixMap; screen = (*pm)->bounds; } -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Now hear a plain fact: Swedenborg has not written one new truth: Now hear another: he has written all the old falshoods. And now hear the reason. He conversed with Angels who are all religious, & conversed not with Devils who all hate religion..." - Blake, "The Marriage of Heaven and Hell"
cc100aa@prism.gatech.EDU (Ray Spalding) (01/08/90)
In article <9530@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Nope. The OpenPort strategy doesn't work on color systems, at least >not in the simple way you seem to be suggesting. If you just look at >port.portBits.bounds, you'll be looking at something weird (a handle >followed by two integers) on color systems. My understanding is that if you use OpenPort() on a color system, you still get an old-style GrafPort. You'd need to use OpenCPort() to get a new-style CGrafPort. You don't need to check for a CGrafPort if you know you're dealing with a GrafPort. -- Ray Spalding, Office of Computing Services Georgia Institute of Technology, Atlanta Georgia, 30332-0275 uucp: ...!{allegra,amd,hplabs,ut-ngp}!gatech!prism!cc100aa Internet: cc100aa@prism.gatech.edu
jmunkki@kampi.hut.fi (Juri Munkki) (01/09/90)
In article <9530@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >Nope. The OpenPort strategy doesn't work on color systems, at least >not in the simple way you seem to be suggesting. If you just look at >port.portBits.bounds, you'll be looking at something weird (a handle >followed by two integers) on color systems. Nope. You are confusing OpenCPort and OpenPort. OpenPort opens a regular grafport with a normal bitmap. I don't think that you bothered to look, but I did and even if I set my Mac II to 8 color, I get a rowBytes of 128 and a bounds of (0,0,480,640). Creating a pixmap for offscreen grafports would have created an enormous amount of incompatibility. OpenPort fakes a bitmap that looks just as if you had a 1-bit screen. That's why the old MacPaint and SuperPaint painted all over the top of the screen. They got a rowBytes of 128 when it actually is 8 times that much. (Although the screen is 640 pixels wide, Apple throws away a few bytes and uses 1024 pixels per row of which only 640 are displayed.) _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._ | Juri Munkki jmunkki@hut.fi jmunkki@fingate.bitnet I Want Ne | | Helsinki University of Technology Computing Centre My Own XT | ^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
beard@ux1.lbl.gov (Patrick C Beard) (01/09/90)
In article <9530@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: # #Nope. The OpenPort strategy doesn't work on color systems, at least #not in the simple way you seem to be suggesting. If you just look at #port.portBits.bounds, you'll be looking at something weird (a handle #followed by two integers) on color systems. # # if ((port->portBits.rowBytes & 0x8000) == 0) # screen = port->portBits.bounds; # else { PixMapHandle pm = ((CGrafPtr) port)->portPixMap; # screen = (*pm)->bounds; # } I've used the OpenPort strategy before and it does work. In fact, if you just open a classic GrafPort, you don't need to go through the tests you show above. I have also just used the portRect field of the GrafPort to give me the same information: ScreenSize(Rect *r) { GrafPort aPort; OpenPort(&aPort); *r = aPort.portRect; ClosePort(&aPort); } Another method is to just use the Window Manager port. Instead of the OpenPort call above, and instead of allocating a GrafPort on the stack you only need a GrafPtr. ScreenSize(Rect *r) { GrafPtr aPort; GetWMgrPort(&aPort); *r = aPort->portRect; } This seems to work on all systems I've tried. ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. ".......<dead air>.......Good day!" - Paul Harvey - -------------------------------------------------------------------------------
tim@hoptoad.uucp (Tim Maroney) (01/10/90)
In article <4594@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >I've used the OpenPort strategy before and it does work. In fact, if you >just open a classic GrafPort, you don't need to go through the tests you >show above. True enough, but the comments about stack space, heap space, and processing overhead still apply. It's far more efficient to just look at screenBits.bounds than it is to open and close a port on the stack. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Genuinely skillful use of obscenities is uniformly absent on the Internet." -- Karl Kleinpaste on gnu.gcc
ech@cbnewsk.ATT.COM (ned.horvath) (01/11/90)
From article <10164@saturn.ucsc.edu>, by sirkm@ssyx.ucsc.edu (Greg Anderson): > [quoted references to invalid screenbits.bounds deleted] > I know it's illegal to call InitGraf() from within XCMD's, but can I > call it from within a DA? It seems like I would have the same problems > you experienced. > > If I cannot call InitGraf() from within my DA, then how can I find the > size of the screen? >>Can anyone tell me, is there a better way to get at global variables >>such as screenBits from within an XCMD? > Sort of -- make callbacks to HyperCard. This won't always get you what you > want, but it can often be very helpful... Assuming that the A5 you "inherit" is valid, and that InitGraf has been called by your host application (which had pretty well ALWAYS be true!), there are a couple of answers. 1. GrafPort myPort; OpenPort (&myPort);...your code here...ClosePort(&myPort); This gives you access to some of the variables you crave. 2. More generally, the low memory global CurrentA5 (long integer at 0x904) contains the address of the address of thePort (the last quickdraw variable) for the current application. So the following code snippet will get you a way to PEEK (never, never, NEVER poke!) at the QD globals: struct qdvars { /* note that the order is the reverse */ long randSeed; /* of that on IM I-204 */ BitMap screenBits; Cursor arror; Pattern dkGray; Pattern ltGray; Pattern gray; Pattern black; Pattern white; GrafPtr thePort; } *myGlobals; myGlobals = (struct qdvars *) ( (**(long**)0x904) - /* address of thePort */ (long)&((struct qdvars *)0)->thePort /* offset of thePort */ ); I presume that if you're not using C you can figure out how to translate that nasty stuff into your own argot. The ugly part with 0x904 gets the address of thePort; the even more bizarre second term evaluates to a constant (at compile time) which is the offset of thePort in the full set of Quickdraw globals. You can now reference myGlobals->screenBits.bounds, for example. The second example works whenever the host application has called InitGraf(), even at interrupt time; most APPLs call InitGraf within micro seconds after launch, so you should be safe. =Ned Horvath=
sirkm@ssyx.ucsc.edu (Greg Anderson) (01/11/90)
In article <9591@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <4594@helios.ee.lbl.gov> beard@ux1.lbl.gov (Patrick C Beard) writes: >>I've used the OpenPort strategy before and it does work. >True enough, but the comments about stack space, heap space, and >processing overhead still apply. It's far more efficient to just look >at screenBits.bounds than it is to open and close a port on the stack. The OpenPort method worked fine for me too, but for the reasons previously mentioned, I'd like to try looking directly at the QuickDraw variables. My question is, how do you reference the A5 register from MPW C? Think's "CurrentA5" isn't recognized in MPW. >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com ___\ /___ Greg Anderson ___\ /___ \ \ / / Social Sciences Computing \ \ / / \ /\/\ / University of California, Santa Cruz \ /\/\ / \/ \/ sirkm@ssyx.ucsc.edu \/ \/
sfleming@cs.strath.ac.uk (Stewart T Fleming IE87) (01/11/90)
In article <9591@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >True enough, but the comments about stack space, heap space, and >processing overhead still apply. It's far more efficient to just look >at screenBits.bounds than it is to open and close a port on the stack. I thought the correct way was to examine the boundary rectangle of the global variable GrayRgn. [Inside Mac V - can't remember the page number] >Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com Stewart Fleming 4th Year Information Engineering University Of Strathclyde Scotland
tim@hoptoad.uucp (Tim Maroney) (01/12/90)
sirkm@ssyx.ucsc.edu (Greg Anderson) wrote: > The OpenPort method worked fine for me too, but for the reasons previously > mentioned, I'd like to try looking directly at the QuickDraw variables. > My question is, how do you reference the A5 register from MPW C? > Think's "CurrentA5" isn't recognized in MPW. To access low-memory globals from C, if you must, you use the macro preprocessor. For instance, you would say #define CurrentA5 (*(long *)0x904) However, when there's a way to avoid low-memory globals, you should do so, because they may go away in the future. In this case, it's better to write a small assembly-language routine that accesses the Quickdraw globals relative to the current value of the A5 register, and returns a pointer to their start. This avoids looking at CurrentA5. Note that if you're going to be doing any graphics, A5 must be set up correctly already, so you can count on it being set to CurrentA5 already in a desk accessory, XCMD, etc. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Everything that gives us pleasure gives us pain to measure it by." -- The Residents, GOD IN THREE PERSONS