MACINTOSH Q & A

MACINTOSH DEVELOPER TECHNICAL SUPPORT

Q Will QuickDraw and QuickDraw GX coexist, or will QuickDraw GX replace QuickDraw?

A QuickDraw isn't leaving with the introduction of QuickDraw GX. It's here to stay. Among other reasons, QuickDraw functions are used extensively by the Macintosh Toolbox and applications. For more information, see the article "Getting Started With QuickDraw GX" in this issue of develop .

Q Will display cards that offer QuickDraw acceleration be affected by QuickDraw GX?

A Current QuickDraw acceleration cards aren't affected by QuickDraw GX. QuickDraw GX doesn't use any of the current QuickDraw calls and its presence won't affect applications that use only QuickDraw. QuickDraw acceleration cards also won't accelerate QuickDraw GX.

Q The LaserWriter driver before the QuickDraw GX version has an option to print in Color/Grayscale or Black & White. Why isn't this option in the QuickDraw GX LaserWriter driver?

A The Color/Grayscale option was added to the LaserWriter driver only for compatibility reasons. At the time, some applications couldn't deal with the color option (specifically with cGrafPorts), so a Black & White mode was also provided. The Black & White mode exhibited the same functionality as the earlier LaserWriter driver 5.2.

Because most applications are color compatible now, the option was removed from the QuickDraw GX printer drivers. Some people reported that the option let them print faster when they chose Black & White. This was true because of quirks in the earlier LaserWriter driver version. Under QuickDraw GX, this shouldn't be a problem. If it turns out to be a problem for your driver, you could incorporate black-and-white threshold printing into your "rough draft mode" code. The QuickDraw GX LaserWriter driver always prints in color.

Q When a QuickDraw GX PostScript printer driver generates a file, will it work for Level 1 and Level 2 printers?

A The LaserWriter driver bundled with QuickDraw GX produces a flavor of PostScript that we call "portable." This flavor is meant to work on the widest range of printing devices, be they Level 1 or 2, color or black and white.

Q What PostScript Level 2 features does the QuickDraw GX printing mechanism take advantage of?

A The Level 2 features used in QuickDraw GX mostly have to do with patterns, text, and bitmaps:

• QuickDraw GX patterns are converted into Level 2 pattern dictionaries when going to a Level 2 printer. The actual PostScript code emitted by the driver differs little with respect to patterns when going to Level 1 or Level 2. However, the procedures defined in the header do something entirely different on a Level 2 printer.
• Line layout in QuickDraw GX takes advantage of the xshow, yshow, and xyshow operators when it makes sense to do so.
• The Level 2 rectangle operators are used in Level 2, though this happens in the procedures defined in the header rather than in PostScript code from the driver.
• On Level 2 printers, the indexed color spaces are used for printing bitmaps up to eight bits deep.
• The plan is to use Level 2 device-independent color when possible.

A You shouldn't call NewMessageGlobals from any routine in which you access your global data. Otherwise, because of optimization that your compiler may perform, the data references can be invalid. Instead, use an approach like this:

extern long A5Size(void);
extern void A5Init(void *);
typedef struct GlobalType {
    StringHandle    aString;
} GlobalType;
GlobalType myGlobals;

/* This routine sets the initial values of our global data. */
OSErr InitGlobalData()
{
    OSErr   err;
    // Initialize our globals.
    myGlobals.aString = GetString(r_myStringID);
    err = ResError();
    if (!err) DetachResource(myGlobals.aString);
    return err;
}

/* Our override for the gxInitialize message. */
OSErr MyInitialize()
{
    OSErr err;
    // Create an A5 world, then go initialize our global data.
    err = NewMessageGlobals(A5Size(), A5Init());
    if (!err) err = InitGlobalData();
    return err;
}

A detailed explanation of the problem accompanies the Kabooms printing extension sample on this issue's CD.

Q A QuickDraw GX printing extension I've already written works fine, but when I install my latest creation, it doesn't show up in the print dialog -- only my old printing extension does. Both extensions are the same except for a few lines of code in their gxDespoolPage message overrides. What's going on?

A Your printing extensions shouldn't have the same creator type. QuickDraw GX requires unique creator types for drivers and printing extensions, just as the Finder does for applications. A creator type must be unique because QuickDraw GX uses it to build its chain of message handlers. If two printing extensions have the same creator, there's no way to determine which is which in the chain. You can register creator types for your printer drivers and printing extensions with the Developer Support Center (AppleLink DEVSUPPORT).

Q Will the SndPlayFromDisk routine in the new Sound Manager version 3.0 work on Macintosh models without the Apple Sound Chip? For the current Sound Manager, is there a good way to tell whether a machine supports SndPlayFromDisk?

A Sound Manager 3.0 supports SndPlayFromDisk on all models. Playing from disk is based on the performance of the machine's SCSI device more than the Sound Manager's performance. In earlier versions of the Sound Manager, SndPlayFromDisk works only on Apple Sound Chip machines. The System 7.1 interface has a play-from-disk Gestalt flag in the sound attributes selector. If this flag bit is set, play from disk is supported. If you're not running System 7.1, you'll have to guess based on whether the version of the system being used has an Apple Sound Chip. So first check for the new Gestalt flag and the presence of Sound Manager version 3.0 or later, which supports this flag. Older versions of the Sound Manager don't report whether play from disk is supported, so you'll have to check for the Apple Sound Chip.

Q Is the Component Manager bundled with QuickTime? In other words, will the users of the application I'm designing have to buy QuickTime in order to get the Component Manager?

A The Component Manager was first introduced as part of the QuickTime 1.0 system extension. This makes the presence of QuickTime a requirement for system software versions earlier than System 7.1. The Component Manager is now part of System 7.1, giving the extended functionality to any Macintosh application running on System 7.1 regardless of the presence of QuickTime.

Q How does the Component Manager handle multiple segments?

A The Component Manager doesn't automatically support multiple code segments. In fact, it assumes that all the code is in one segment. The 'thng' resource allows you to specify one segment. Therefore, if you load other code segments from your main segment, they should be loaded and locked in the system heap. There are several ways you can do this; the register routine probably is the best place to do it. Since the register routine is called only once at registration time, this allows your component to completely load the remaining code segments into the system heap. Components should ensure that A5 (or A4) is set appropriately before any intersegment calls. For more information, see "Managing Component Registration" in this issue of develop .

Q How can I get answers to my Macintosh Common Lisp questions?

A Macintosh Common Lisp technical support is available on the Internet at the following addresses (add "@internet#" for the corresponding AppleLink addresses):

• bug-mcl@cambridge.apple.com, which reaches the MCL team
• info-mcl@cambridge.apple.com, which reaches MCL users at large

You can join the info-mcl list in one of the following ways:

• Contact info-mcl-request@cambridge.apple.com on the Internet to add your address to the list.
• Join INFO.MCL$ on AppleLink by contacting ST.CLAIR.
• Check comp.lang.lisp.mcl on Internet netnews.

MCL utilities and sample source code are available in these places:

• on the MCL 2.01 CD-ROM (available through APDA)
• on the Developer CD Series disc (Tool Chest edition) and the develop Bookmark CD
• on the Internet, by anonymous ftp from the location cambridge.apple.com:/pub/MCL2/contrib

Q Can I assume that the value of the ColorSync CWorld parameter returned by the CWNewColorWorld routine isn't null if the routine was successful? I'd like to determine whether a color world exists by checking the variable for null.

A You can assume that if no error is returned by CWNewColorWorld, the CWorld parameter will be a valid handle. In other words, it won't be null if no error is returned.

Q The icons that appear in our application's menu lists are very, very small. It looks like they're 8 x 8 (scaled) instead of the standard 16 x 16. Can you tell from our test code why this is happening?

A This was a wild one! What's causing the weird behavior is that you have a 'cicn' resource with ID = 256 that's smaller than 32 x 32. When the MDEF finds such an icon, it uses it to size the area to use for the menu icons. So, for your application the solution is either to change the 'cicn' to be larger (32 x 32) or to give it a different ID.

Q I've installed a resource error procedure (ResErrProc) but it gets called with an error -192 (resNotFound) every time I release a resource. Why is this happening and what can I do to fix it?

A If you install a ResErrProc, the Process Manager switches it out when switching to another application. The problem you're having is that the Process Manager doesn't switch it out while in Process Manager code itself. If you break into the debugger in your ResErrProc and examine register A5, you'll find it's not your A5; it is in fact the Process Manager's.

What has happened is that the Process Manager has patched ReleaseResource for its own mysterious purposes. An error occurs, which the Process Manager believes it can ignore, but because your ResErrProc is still installed, it gets called and reports the error. To avoid this, when your ResErrProc gets called, check to see whether register A5 is equal to the low-memory global CurrentA5. If the values aren't equal, you can assume your application wasn't responsible for the error, so you can ignore it.

The code might look like this:

 
void MyResErrorProc (void)
{
    long    A5;
    A5 = SetCurrentA5 ();
    if (A5 == *(long *)CurrentA5)   /* If they're equal, we're in
                                        current app code */
        Debugger(); /* ...or whatever you want to do here */
    else /* Not in current app code */
        SetA5 (A5); /* Restore old A5 */
    return;
}

Similar problems can occur if you make calls that make other Resource Manager calls. The secondary calls may produce errors that are inconsequential to the primary call, but your ResErrProc gets called anyway. This makes ResErrProcs of limited use, so use any information reported by a ResErrProc carefully.

Q We can't apply the rotation and skew effects to a QuickTime 1.5 movie. We've created an identity matrix, applied RotateMatrix to the matrix, set the matrix to the movie using SetMovieMatrix, and played the movie. The movie didn't rotate but the movieRect rotated and the movie scaled to the movieRect. Is there anything wrong with what we're doing?

A Rotation and skew will give you correct results for matrix operations but they haven't been implemented into QuickTime movie playback yet. Scaling and offset transformations now work with movies and images; rotation and skew are important future directions. Meanwhile, you can accomplish rotation and skewing by playing a movie to an off-screen GWorld and then using QuickDraw GX to display the rotated or skewed off-screen GWorld.

Q The demo programs on the final QuickTime for Windows CD won't run without locking up, because the QTInitialize function doesn't return. Any ideas?

A The final QuickTime for Windows exhibits the behavior you describe when the display board is configured in a way that QuickTime for Windows doesn't recognize. XGA and SuperVGA are modes that could cause this problem. To check whether this is the problem, edit the QTW.INI file to include the following:

[Video]
Optimize = Driver

The default is Hardware. This could be causing the problem you describe.

Q While updating our application to run correctly under the Kanji version of System 7.1, we've noticed that the space bar sends two key-down events (values $81 and $40) as opposed to one ($20). To determine whether the space bar was hit, should we use the key code from the event record instead of the character code?

A This is new with Kanji 7.1 and is still a controversial issue. Codes $81and $40 correspond to the two-byte space character, which is different from the standard ASCII space character (different width).

You can't use the key code from the event record, as it has been lost during KanjiTalk's event processing. Moreover, even if it were there (or if you got it through a GetKeys call) you shouldn't use it; the space bar has different key codes on different keyboards!

So, the only reasonable workaround in your case seems to be to expand your space bar key- down check to compare with $81 (the first byte of a two-byte character) followed by $40, in addition to comparing with the standard ASCII $20.

Q What kind of resources are available to incorporate WorldScript capability to our programs?

A The first thing to do to support WorldScript is to make sure that your product takes full advantage of the Script Manager. The most up-to-date and comprehensive reference for learning about it is Inside Macintosh: Text . Be sure to check the QuickDraw Text and Text Utilities chapters, because much of the old Script Manager functionality has been moved into those areas. Other references are Guide to Macintosh Software Localization and Localization for Japan . These are all available through APDA. (If compatibility with system software versions before System 7.1 is important to your application, see the earlier documentation: the Script Manager and Worldwide Software Overview chapters of Inside Macintosh Volumes V and VI, and Macintosh Worldwide Development: Guide to System Software .) See also the Text Services Manager chapter of Inside Macintosh: Text .

In general, all the rules for being Script Manager-compatible apply, but with a few new twists. WorldScript is still a very young technology and there isn't a lot of detailed information yet. Some human interface issues have not matured to the point of being ready to standardize. This means that you might find yourself breaking new ground as you add WorldScript support to your application.

The Japanese Language Kit is the first new product to take advantage of WorldScript. All the non-Roman system software uses WorldScript but doesn't really take full advantage of the possibilities.

The main advantage of WorldScript is that it supports multiple scripts in a system. The old model was that there could be a Roman script plus one other optional script, and Roman was always the secondary script, unless it was the only script. Now, any script can be the primary script, and there can be multiple secondary scripts. (Roman is still required to be available.) This makes it possible to have Japanese (and in the future, other scripts) installed as secondary scripts in any system.

Because many of the Macintosh Toolbox and operating system routines don't pass script or font information with text, it's difficult to display multiscript text properly. Menus, dialogs, window titles, and filenames are problem areas. A short-term solution is the Language Kit Extension, which was introduced in the Japanese Language Kit. It dynamically changes the system fonts according to the region code in each application's 'vers' resource. This allows localized applications to display menus, dialogs, window titles, and filenames correctly. Multiple applications running concurrently can have independent system fonts.

The Language Kit Extension also extends the Views control panel to control the current script and font for the entire file system. This allows the user to display, create, and edit filenames for any script installed. Note that this solution supports only one script at a time, and fundamental changes will have to made to the Toolbox to support more than one script concurrently.

A technical overview of potential internationalization problem areas is given in the "Internationalization Checklist" on this issue's CD. Internationalization tips are also provided in "Writing Localizable Applications" in Issue 14 of develop . Here are some areas requiring special attention:

• Font names should be displayed in menus in their appropriate script and font.
• The system (primary) script may not be the same as the application script.
• Script system resources (date/time/currency) should be referenced explicitly.
• Text should be tagged with script and font information so that it can be displayed in its appropriate script and font.

Styled text and QuickDraw GX are multiscript-capable and should be used as much as possible. Unstyled text documents limit text to one script (character set), which is undesirable.

Ideally, the localized version of a product should be independent of the scripts and languages it supports. With Macintosh multiscript support and today's cultural diversity within nations, users want "foreign language-capable" applications that let them mix writing systems and use familiar regional formatting conventions.

Here are a few tests to see how well you're doing:

• Does the base version of your application work on all localized versions of system software (such as KanjiTalk, Arabic, German)?
• Install the Japanese Language Kit and see whether your application supports multiscript text. Try using the two-byte Japanese script with a relatively simple script such as German, and then with a bidirectional script such as Arabic.

Q We're planning to distribute a custom font with our application, by including the FOND and NFNT resources in its resource fork. Are there any problems we might be overlooking by using this technique?

A There are things you must be aware of when embedding fonts in applications. First, no ID conflict resolution is done. Since the system caches some fonts for performance reasons, if your font has the ID of a font in the system, you can't predict whether you'll get your font or the system's font. Second, you must use NFNT instead of FONT resources for bitmap fonts, or the system will sometimes get the wrong font strike. This is described in the Macintosh Technical Note "Fond of FONDs" (Text 21). You should never try to override a font in the System file with one in your application; the name of your custom font should be different from all other font names. If you don't want your font to show up in menus, give it a name beginning with a period or "%" so that AddResMenu will ignore it.

While most printer drivers and the system take pains to find fonts wherever they may be, some software components don't, and we can't promise this will work with all printers or all software. While installing fonts in an application should work for most purposes, it's preferable all around for you (and your customers) to install your fonts in the system. Of course, you should always ask for your font by name in your code.

Q When I try to use the MDEF mDrawMsg to draw the contents of the pop-up box for a pop-up menu, if the system justification is right to left and I send it mDrawMsg with a rectangle that's too short, the system hangs unless I move the left edge of the rectangle off to infinity and use clipping to constrain the drawing. Is there a better way to do this?

A There may be an easier way to achieve the same result. The standard MDEF has been modified to support two new messages to do exactly what you need. In fact, this was added to support the System 7 pop-up menu CDEF. For an MDEF whose entry point is defined as

void pascal MyMenu (short message, MenuHandle theMenu, Rect
    *menuRect, Point *hitPt, short *whichItem);

the two new messages are mCalcItemMsg and mDrawItemMsg. In response to mCalcItemMsg, the MDEF calculates the bounding rectangle of a menu item:

Input parameters:
message = mCalcItemMsg = 5
theMenu = handle to pop-up menu
menuRect.top and menuRect.left = screen position at which to draw menu
hitPt = not used
whichItem = menu item to calculate the size for

Output:
menuRect.bottom and menuRect.right, calculated for correct size for whichItem

In response to mDrawItemMsg, the MDEF draws an item in a menu:

Input parameters:
message = mDrawItemMsg = 4
theMenu = handle to pop-up menu
menuRect = rectangle to draw item in
hitPt = not used
whichItem = menu item to draw

* Output:
Draws item whichItem of menu theMenu in rectangle menuRect. menuRect is determined by first calling the MDEF with mCalcItemMsg.

These messages may be ignored by other menu definition procedures; they're optional. If you find that your rectangle wasn't resized after an mCalcItemMsg call, the MDEF has probably ignored your size request, and you should do it manually. The standard MDEF will continue to support these options.

Q We create an alias for a file when File Sharing is off, so the alias doesn't contain server and zone information. Then we turn on File Sharing and resolve the alias. The file, of course, is found but the alias isn't marked for an update. Shouldn't it be updated?

A According to Inside Macintosh: Files, wasChanged is set to TRUE only on aliases created by NewAlias (not NewAliasMinimalFromFullPath or NewAliasMinimal) when it sees that key information has changed. The key information is:

• name of the target
• directory ID of the target's parent
• file ID or directory ID of the target
• name and creation date of the volume on which the target resides

Since none of that changes when you turn File Sharing on or off, the wasChanged flag isn't set to TRUE. If you're really worried about it, just call UpdateAlias every time you use the alias (unless you think this would be a major performance hit). Or maybe you should update it only if you notice that it doesn't have server information and the server is now turned on (to check for this, call PBHGetVolParms and check the bHasPersonalAccessPrivileges bit).

Q When I try to compile some C++ code that I'm porting from another platform, I get the error message shown below. Can you shed some light on what the error means? I can avoid it by removing labels, but sometimes it's difficult to fix. What's the real cure?

# 4:14:35 PM ----- Executing build commands.
    CPlus -s tops1 -model far -sym on -mf test.cp
    Set Echo 0
File "test.cp"; line 704 # sorry, not implemented: label in block
with destructors

A The error message is correct; labels in a scope that locally defines objects with destructors aren't supported. The most appropriate fix would be for AT&T to fix their CFront code to support this, but that's not going to happen right away.

The variety of twisted code paths that become possible when labels and gotos are used probably gave the compiler programmers conniptions. When code can contain constructors and destructors, the C++ compiler has to be extremely careful to construct each object only once and destruct each object only once. This probably was a problem for the C++ compiler if gotos were allowed, so the compiler programmers must have chickened out and didn't write the necessary code (at least, not yet). The only solution to this error is either to avoid the label and goto constructs (which you've been trying to do) or to keep any objects with destructors out of the block that contains the label.

Q I want to use sprintf in a standalone code resource, but I'm having trouble linking my resource because sprintf apparently requires data-to-code references. I get the error shown below; what can I do to avoid this?

### While reading file "HD:MPW:Libraries:Libraries:Runtime.o"
### Link: Error: Data to Code reference not supported (no Jump
Table). (Error 59)
### Link: Errors prevented normal completion.

A Unfortunately, a great deal of the standard C library uses globals, which necessitates your creating an A5 world as described in the Macintosh Technical Note "Stand-Alone Code, ad nauseam " (Platforms & Tools 35). Additionally, some of the global data used is initialized with function pointers. For example, if you had the following global variable defined

 ProcPtr  gMyProcedure = (ProcPtr)MyFunc;

where MyFunc is a function of yours, you can see that the global variable would have to be initialized with a pointer to the function before your code started executing. MPW's loader supports only pointing variables such as these at A5-relative references -- that is, into the jump table. It cannot initialize them to the PC-relative reference that a standalone code segment requires. This means that you can't link any code resource that requires a data-to-code reference -- thus the error.

Fortunately, there's a workaround. Because the standard library is written very generally and uses a lot of indirection, the linker believes sprintf might use some of the standard output calls; however, it never does, and since it's these calls that necessitate the use of the data-to-code references, if we can fool the linker into accepting an innocuous substitute, we won't require the data-to-code references that are causing us such agony now. To cut to the chase, add the following lines to your code somewhere:

size_t fwrite (const void *, size_t, size_t, FILE *) { return 0; }
flsbuf() {}       // These calls won't actually be called by sprintf.

fcvt() {}         // These calls are used only for floating-point %f
ecvt() {}         // and %e. 

The first two calls override fwrite and flsbuf; these calls will no longer cause the linker to believe that you require the data-to-code references; because they're never called by sprintf, replacing them isn't a difficulty. The second two calls are only conveniences; they stub out the standard library's code for converting floating-point arguments. If you never use %f or %e in your sprintf calls, these will reduce the size of your compiled code.

To get these overriding functions to mask the versions in the StdCLib.o library, make sure that the object file containing these stubs appears on the Link command line before the StdCLib.o library.

Q Why does calling FSpCreateResFile return an afpAccessDenied error (in ResErr) when the destination folder is an AppleShare drop folder?

A Using any of the CreateResFile calls in a drop box is a useless exercise. Here's why: The access privileges within a drop box are very limited write-only access. This lets you create new files and then perform a small set of operations on the file while it's empty (no bytes in either the data or the resource fork of the file). So, while the file is empty, you can open it (either fork) with write-only access (PBHOpenDeny or PBHOpenRFDeny), and write the file's attributes (PBHSetFInfo or PBSetCatInfo), including Desktop Manager comments. Once either fork has a single byte of data written to it, you can no longer open or change the file's attributes. This makes it possible to copy a file into a drop folder, but not to manipulate or delete a file (containing data) that's already in the drop folder. You can also move a file or directory into a drop folder if that file or directory is already on the same server volume.

So, when you call CreateResFile on a drop folder, a new file is created and data is added to the resource fork of the file. Since the file now has data in one of the forks, you cannot open the file or change any of the file's attributes. FSpCreateResFile fails because after performing the CreateResFile operation that writes data into the resource fork, it attempts to set the file's attributes (creator, fileType, and scriptTag).

For a quick explanation of drop folder access privileges and rules, see the Macintosh Technical Note "Creating Files Inside an AppleShare Drop Folder" (Files 18). For a complete explanation of what AFP access privileges you need to perform specific operations on an AppleShare (AFP) server, see the section "Directory Access Control" in Inside AppleTalk starting on page 13-31.

Q When I try to send an OpenSelection Apple event to the Finder, I get a -903 error after calling AESend. Could you tell me what causes this error and how I can overcome it?

A The application is returning the -903 error because it isn't completely set up to send and receive Apple events. This is why you're getting the error only after calling AESend. The problem is that the isHighLevelEventAware bit isn't set in your SIZE resource, meaning that your application doesn't send or receive high-level events. For more information on setting the isHighLevelEventAware bit, see Inside Macintosh: Macintosh Toolbox Essentials , pages 2-115 through 2-119 (or Inside Macintosh Volume VI, pages 5-14 through 5-17).

Q When we launch our Macintosh application, the system heap grows by huge amounts. It seems to be filling up with font-related resources. What's causing this to happen?

A Your application is probably calling RealFont for each font installed in the system. Trying to build lists of font information at startup nearly always balloons the system heap to enormous sizes if you have lots of fonts.

When you call RealFont, the system must load the FOND resource and walk through the association table to see if there's a bitmap for it. If there's a TrueType font, the Font Manager loads the 'sfnt' resource and examines it. A value inside TrueType fonts says "I don't render smaller than this resolution"; if the requested resolution is smaller than that value, RealFont returns FALSE even on a TrueType font. For most of Apple's TrueType fonts the value is about 6 points -- calling RealFont(2, Helvetica) will return FALSE.

So the system is loading every FOND and 'sfnt' looking to see whether the fonts are real. The main solution is not to call RealFont until you're sure you need the information. For example, don't outline Size menus until just before they're accessed or until a new font is chosen, to prevent this kind of problem.

Q I just wrote an installer script for the Apple Installer version 3.4. After the installation is complete and I click the Quit button, the Finder insists on mounting both of the disks that were used in the installation. It gives me the annoying dialog "Please insert the disk Install 1" and "Please insert the disk Program 1." Before I did the installation, only the Install 1 disk was mounted by the Finder. Why is this happening?

A This situation typically occurs when the installer disk sets were created under System 7 and the installation is happening under system software version 6.0.x. Its cause is that the system is trying to update the second disk's desktop. The solution in this case is to insert the disk into a system running version 6.0.x before performing the installation.

Another possible cause for this problem is that the second disk opens to display a window by default. When the Installer quits, there's still "residue" Finder information to be written to the second disk, which has since been ejected. The solution in this case is to insert the second disk with the write tab lock disabled, and close any open window associated with that disk.

Q I received an error code of -151 from NewGWorld when creating a very large off-screen bitmap. Does this mean not enough memory? If so, can I count on it not to change in future versions of the system? It's not listed as one of the possible errors in Inside Macintosh Volume VI.

A The error -151 is cTempMemErr, "failed to allocate memory for temporary structures," or in other words, there wasn't enough temporary memory available for NewGWorld. NewGWorld returns this error after it receives a memFullErr from TempNewHandle. (See Inside Macintosh: Memory or the Memory Management chapter of Inside Macintosh Volume VI for more information about temporary memory.) This was inadvertently left out of Inside Macintosh Volume VI but does appear in the MPW interface files. You can count on this error code in future versions of system software.

Q SetStylHandle appears to dispose of only the TEStyleHandle in the TextEdit record and not the handles in the TEStyleRec in system software version 7.0.1. Since my application calls SetStylHandle often, I'm leaving lots of little handles around in my heap. Can I safely dispose of the handles in the current TEStyleRec before calling SetStylHandle?

A SetStylHandle does indeed orphan the related handles in your heap, a potential problem for applications using SetStylHandle. This won't be fixed in the foreseeable future. Your application will be fine disposing of the handles itself. Here's a routine you can use instead of SetStylHandle; it correctly disposes of the substructures in the TEStylRec before calling SetStylHandle:

void FixedSetStylHandle(TEStyleHandle newstyle, TEHandle hte)
/*
    This function avoids orphaning the substructures of a 
    TEStyleRec by disposing of them before calling SetStylHandle.
*/
{
    register TEStyleHandle oldstyle;
    /* Get the old-style handle so that we can clean it up. */
    oldstyle = GetStylHandle(hte);
    /* Dispose of the substructures first. */
    DisposeHandle((**oldstyle).styleTab);
    DisposeHandle((**oldstyle).lhTab);
    DisposeHandle((**(**oldstyle).nullStyle).nullScrap);
    DisposeHandle((**oldstyle).nullStyle);
    /* Now we can install the new style. */
    SetStylHandle(newstyle, hte);
}

Q I was hiking in a remote part of the Rocky Mountains and could have sworn that I saw the familar Macintosh beach-ball cursor. Is this possible?

A Yes; that's the same symbol that's used to signify a ranger station. It could also be that you were hallucinating. (By the way, develop 's Editor-in-Cheek tells us that the beach-ball cursor can also be found on the reverse of an Eastern Caribbean $5 bill; she took a special field trip down there just to check this out.)

Kudos to our readers who care enough to ask us terrific and well thought-out questions. The answers are supplied by our teams of technical gurus in Apple's Developer Support Center; our thanks to all. Special thanks to Pete ("Luke") Alexander, Mark Baumwell, Joel Cannon, Matt Deatherage, Tim Dierks, Nitin Ganatra, Bill Guschwan, Mark Harlan, C. K. Haun, Dave Hersey, Rich Kubota, Jim Luther, Joseph Maurer, Kevin Mellander, Don Moccia, Ed Navarrete, Guillermo Ortiz, Faith Pai, Dave Radcliffe, Brigham Stevens, Steve Strassmann, Dan Strnad, John Wang, and Dave Wells for the material in this Q & A column. *Have more questions?

Need more answers? Take a look at the Macintosh Q&A Technical Notes on this issue's CD and on the Dev Tech Answers library on AppleLink.*