Technical Questions Answered

By Steve Brecher, Software Supply, MacTutor Contributing Editor

Coordinate Systems

Q. Moving a window by using MoveWindow(..., <portRect.left+offset>, <portRect.top+offset>, ...) doesn't work. What do I need to do?

A. The coordinates you pass to MoveWindow must be global coordinates, so transform them with calls to LocalToGlobal first. The distinction between local and global coordinates can be confusing (it was to me, anyway), so let's discuss coordinate systems.

A coordinate system is an abstraction. I visualize it as an infinitely large sheet of graph paper with one intersection of grid lines designated 0,0. By assigning one grid intersection (0,0 or any other ) to a specific bit in memory, we thereby are able to refer to pixels (memory bits) in terms of coordinates rather than in terms of RAM addresses. This is very convenient when thinking about graphics.

The QuickDraw bitmap is what associates a particlar coordinate system (graph paper) with a particular set of memory locations.

Think of the sheet of graph paper thumbtacked to a bit in memory. The thumbtack goes through the graph paper at the intersection designated by the top, left coordinates of the bitmap's bounds rectangle; this can be any intersection at all -- it needn't be 0,0. The tack's point sticks into memory at the location designated by the bitmap's baseAddr.

A point expressed in local coordinates is merely one that has been thus assigned to a pixel as specified by the relevant grafPort's bitmap. Each and every coordinate found in a grafPort (in the sense of a field in a Pascal record) is, by definition, local to that grafPort.

When we wish to compare the locations with respect to memory (screen) of points in two different grafPorts, we must adjust their coordinate systems so that the same intersection on each port's graph paper is assigned ("thumbtacked") to the same pixel. The convention for doing this is to "move" each graph paper so that its 0,0 coordinate is at the lowest-addressed pixel. Note that this method of inter-port comparison works only if both lowest-addressed pixels (baseAddr's) are the same! This implied requirement -- satisfied, of course, if both baseAddr's are equal to screenBase -- is usually taken for granted in IM discussions.

A local coordinate is an expression of vertical and horizontal distance from the 0,0 intersection on the particular piece of graph paper associated with a grafPort. A global coordinate is an expression of vertical and horizontal distance from the baseAddr pixel. If (and only if) two ports have the same baseAddr, then global coordinates from each may be compared and yield a valid graphics relationship.

While the QuickDraw chapter of Inside Macintosh says (of two ports being compared) "using the same bit image (such as the screen)", the rest of IM when using the term "global" takes for granted that the screen is in fact the common bit image for both ports.

When IM says a document being drawn "sticks to the coordinate system," I mentally translate that to "sticks to the graph paper"; similarly, I mentally translate "sticks to the screen" to "sticks to memory."

Of course, the memory locations designated by a bitmap do not have to coincide with the memory from which the screen is displayed. Drawing merely affects the memory designated by the bitmap; if that memory is (all or partially) in the screen buffer, then the screen display will be affected.

QuickDraw Regions Limitation

Q. L. Tannenbaum of Long Beach, CA, submitted some MacFORTH code that illustrates a problem with QuickDraw's handling of complex regions. His program created 17 vertically-oriented rectangles while defining a region. Subsequently FrameRgn didn't seem to work correctly. He wants to know if the problem is in his code or in QuickDraw.

A. By doing some experiments ,and with the help of MacsBug, I analyzed the problem as follows.

There is a problem in QuickDraw's handling of regions containing more than 12 vertical (higher than wide) rectangles. FrameRgn of a region containing more than 12 vertical rectangles will paint them instead of frame them, and rectangles after the 12th (from left to right) will be enlarged horizonally.

If there are more than 24 such Rectangles, FrameRgn will crash with an address error.

The problem seems to be due to the way region information is stored, in conjunction with the fact that some routines (e.g., FrameRgn, possibly as a part of code common to other routines) allocate a fixed amount of space on the stack which is not large enough to accommodate a chunk of information recorded for the region.

For (at least) multiple rectangles, region information is stored in chunks consisting of pairs of arrays of coordinates in the form

  top[i]         left[1] right[1] left[2] right[2] ... left[n] right[n]
  bottom[i]    left[1] right[1] left[2] right[2] ... left[n] right[n] 

where i ranges over 1 to the number of horizontal lines on which the rectangle corners lie, from top to bottom of the grafPort's portrect. Each array is terminated with a $7FFF marker.

For horizontally-oriented rectangles, n=1, and each array contains exactly 3 coordinates. For vertically-oriented rectangles, n is equal to the number of rectangles, and each array is therefore potentially large. QuickDraw appears to do a Link A6,#-562, and part of the stack frame thus allocated appears to be filled with a chunk of coordinates via autoincremented A2 as the destination address of a move loop. If the chunk is too large, stack frame underflow will result.

I submitted the above to Apple's Tech Support team, and Ginger Jernigan replied:

"It isn't a bug, it is a limitation in QuickDraw, which will be documented in the final version of Inside Macintosh. Your analysis of the situation was correct. We're working to fix it or at least alleviate the nasty problems that occur (like getting real syserrors from Quickdraw calls)."

Boldly Outlining Buttons

Q. Mike Scanlin asks: how do you get the thick border to outline a button in a dialog box for the button representing the default if the user hits Return (usually either "OK" or "Cancel")?

A. Usually such button highlighting appears in alert boxes. The Dialog Manager automatically highlights either item 1 or item 2 in an alert box. Whether item 1 or item 2 is highlighted depends on the value of a bit in the "stages" word for the current stage of the alert. (See Inside Macintosh, Dialog Manager, pp. 34-36.)

The stages word is located in the ALRT resource, and is divided into four 4-bit parts, each part governing one stage, or consecutive occurrence, of the alert. One bit in each part governs item highlighting; if the bit is clear, item 1 is highlighted, and if it's set, item 2 is highlighted.

Often item 1 is an "OK" button and item 2 is a "Cancel" button, and IM assumes this in its illustration. But in fact the Dialog Manager will highlight item 1 or item 2 regardless of what kind of item it is. This can somethimes be a problem. For example, if you have an alert with only a message (a statText item) and an "OK" button, you don't want any highlighting. But the Dialog Manager will relentlessly highlight either item 1 or item 2; if the statText is item 2 and the appropriate bit in the stages word is set, the text will have an ugly bold round-corner rectangle drawn around it. If the bit is clear, the "OK" button will be highlighted, which would be silly since it's the only enabled item.

The only way to handle such a situation is to add a dummy item to the alert's item list (such as a one-character statText item located outside of the alert's rectangle) and let that dummy item "take" the highlighting. In our example, the dummy item could be item 1, and the bits in the stages word would be clear so that item 1 is highlighted. To see an example of this technique, use ResEdit to examine the Finder's DITL 129 resource.

To highlight a button in a dialog that is not an alert, you can use a userItem. Usually a userItem just draws a non-standard item, such as a picture. In this case, we can employ a userItem to change the appearance of another item -- namely, of our button.

A userItem consists of a procedure, as documented in IM, Dialog Manager, p. 11. We will ignore the itemNo parameter, since the item that the userItem will be operating on is not the userItem itself, but the button we want to outline. The QuickDraw techniques for boldly outlining a button are shown on p. 13 of the Dialog Manager section:

PenSize(3,3);
InsetRect(displayRect,-4,-4);
FrameRoundRect(displayRect,16,16)

--where displayRect is the button's display rectangle; GetDItem can be used to obtain it.

Print Dialogs

Q. Paul Cozza of Long Beach, CA, asks: two undocumented Printing Manager routines -- PRSTLINIT and PRJOBINIT -- were mentioned on p. 32 of the First Draft (6/11/84) of Printing Manager section of Inside Macintosh. Apple promised documentation in a later release of the manual, but the routines have mysteriously disappeared altogether from the latest version (Second Draft, 3/27/85, distributed with the May 1985 Software Supplement). If these routines are now unavailable, what is the way to modify the print style and job dialogs?

A. My guess is that the routines succumbed to the generalization of printing procedures that was necessitated by the advent of the Laserwriter.

In the Imagewriter file (I'll let you know about the Laserwriter as soon as I can afford one!), the style dialog is the DLOG -8192 resource, and the job dialog is DLOG -8191. If you examine DITL (dialog item list) -8192, you'll see only placeholders where the paper sizes appear in the style dialog.

At least with respect to Imagewriter paper sizes, it is possible to make some changes. The PREC 3 resource in the Imagewriter file specifies the names of the papers as they will appear in the style dialog, and the sizes of the paper. The format of the PREC 3 resource is as follows:

n [1-word count] -- number of paper sizes;

n pairs of words -- vertical,horizontal paper size in 120ths of an inch;

n Pascal-format strings -- names of paper sizes;

1 word -- ? (probably flags for Orientation, Pagination, Reduction).

Up to six paper sizes can be accommodated by the style dialog box. The distributed Imagewriter file PREC 3 resource contains the specifications of five sizes (US Letter, A4 letter, US Legal, International Fanfold, Computer Paper).

As to other aspects of the dialogs I'm afraid you're on your own; I note the following warning in IM : "Your application should not change the data in the print record -- be sure to use only the standard dialogs for setting this information."