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:
Q Why can't I get NewMessageGlobals to work in my gxInitialize message for my
QuickDraw GX printing extension? The global data I try to initialize isn't being
accessed correctly.
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):
You can join the info-mcl list in one of the following ways:
MCL utilities and sample source code are available in these places:
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:
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:
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:
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.*