Q Is it my imagination, or does GetPictInfo return a bit depth of 1 on QuickTime
compressed PICT files?
A Yep! This is what's happening: The Picture Utilities Package doesn't know of the
QuickTime Compressed Pixmap opcode (0x8200), so it just skips over the opcode's
data; then it finds the PacksBitRect opcode containing the black-and-white
pseudo-alert that you get when you draw the picture on a machine that doesn't have
QuickTime installed, and GetPictInfo reports back this alert.
Trivia: When QuickTime is installed, it displays the compressed image and then
ignores the following PacksBitRect since QuickTime knows it's only the
black-and-white alert.
Q Is it true that if I double-click a document belonging to my application, the
application will be launched and will receive an 'odoc' Apple event, but will not receive
an 'oapp' event--that is, it will receive either 'odoc' or 'oapp' but not both?
A Yes, except actually it will receive one of 'oapp', 'odoc', or 'pdoc'. The 'pdoc' will be
followed (as the next event) by a 'quit' if the 'pdoc' was the event sent as the
application was launched.
This is the normal sequence of events, and should be adhered to by everyone who
launches applications. However, it isn't enforced by the system or the Finder. It's
possible for any application to launch your application with any event, since it can
stuff anything in the launchAppParameters field of LaunchApplication, as long as it's a
valid high-level (not even Apple) event. Launching another application this way would
be bad programming, and would break most applications, but you should be aware that
someone who doesn't understand event handling may do this to you.
Note that if another application launches your application using LaunchApplication and
doesn't specify any high-level event in the launch parameter block, the Finder will
automatically supply the 'oapp' event. So, in general, if Apple events and launching
have been coded correctly, you'll always receive an 'oapp', 'odoc', or 'pdoc'.
Q I'm using the Picture Utilities Package to extract the color table from a picture.
After getting the color table, I use NewPalette to construct a palette from the color
table (usage = tolerant, tolerance = 0). After I do this, the RGB values in the palette
don't always exactly match the RGB values in the source color table, causing my
program to fail. If I use NewPalette without a source color table, and then use
CTab2Palette to copy the colors over (again with usage = tolerant, tolerance = 0), the
colors match exactly.
A It turns out that NewPalette doesn't use CTab2Palette, but copies the RGB fields in a
strange way that's causing the problems you're seeing. NewPalette copies the high byte
in each color table RGB entry into both the high byte and the low byte of the
corresponding palette entry. Thus, if the color table entry for red was $F000, it
becomes $F0F0. This of course makes no difference to QuickDraw since the low byte
isn't displayed, but if your program expects the low byte to match, that's where your
problem exists. CTab2Palette is different, in that it doesn't copy the high byte into the
low byte unless the pmAnimated bit is set.
The best solution for your code isn't to compare the entire RGB value when comparing
colors, but rather to compare the high byte of each RGB component separately. If this
isn't possible, the next best solution is for you to use the workaround that you've
already discovered with CTab2Palette. It's unlikely that the Palette Manager is going to
change in the future for something like this. In fact, we would almost call it a "feature"
since other developers may even depend on it.
Q My application wants to open other applications and play with the resources therein,
like ResEdit, but when it calls OpenResFile on an application, the program gets lost in
GetNamedResource. Is there something I'm missing?
A Your problem stems from the fact that some resources in the application file you're
opening with OpenResFile are marked to be preloaded, and so are loaded into memory
when the resource fork is opened.
Since most applications have CODE resources marked to be preloaded, this turns into a
much bigger problem, because the Segment Loader will treat these preloaded CODE
resources as your code resources if you make a between-segment call that triggers a
call to LoadSeg while the opened resource file is first in the resource chain. If this
happens, you'll begin executing code out of the other application, which will cause
your Macintosh to crash and burn.
The solution to this problem is to bracket OpenResFile calls with SetResLoad(FALSE)
and SetResLoad(TRUE), and to avoid making between-segment calls when you've got
another resource file open that contains CODE resources. This will not only prevent
your application's memory from being used by preloaded resources that you don't
want, but will also prevent the Segment Loader from jumping into the other
application's code. If you need to get CODE resources out of the opened resource file,
you can still prevent the Segment Loader problem by calling UseResFile on your
application's resource reference number to put your application at the top of the
resource chain.
Q How can our application search for files by label or color, getting the actual string
for the label/color field, so that users can select from a menu that looks like what
they'd see in the Finder or ResEdit?
A In the icon utilities there's a call that will get you the RGB color and string for the
Finder's labels. Information from the May 1992 revision of Macintosh Technical Note
"Drawing Icons the System 7 Way " (formerly #306) is shown below. It includes the
glue code for the call in MPW Pascal and C formats.
FUNCTION GetLabel (labelNumber: INTEGER; VAR labelColor: RGBColor;
VAR labelString: Str255): OSErr;
INLINE $303C, $050B, $ABC9;
The label number is in the range of 0 to 7, and is available in bits 1-3 of the file's
Finder flags (Inside Macintosh Volume VI, page 9-36). The call returns the actual
color and string used in the Label menu of the Finder and the label's control panel. This
information is provided in case you want to include the label text or color when
displaying a file's icon in your application.
Q I'm making an asynchronous low-level File Manager call from inside a completion
routine (for example, error := PBxxx(@PB, TRUE);). Occasionally on some
machines, the call immediately returns an error in the function result even though
everything appears to work correctly. Do I need to worry about the result when I make
the call?
A It sounds as if you're making the mistake of testing the function result of an
asynchronous File Manager call (the value of register D0 is returned in the function
result). There's no useful information in the function result of an asynchronous call
made to the File Manager; the call might not even have been looked at by the File
Manager yet. The call's result status is stored only in ioResult after the call completes,
or in either D0 or ioResult at the entry to the completion routine. If you're polling to
check for the call's completion, ioResult will indicate the call has completed when it's
less than or equal to 0. In general, when making asynchronous I/O calls (reads or
writes) there are only two types of function result error that are of any possible
consequence: a "driver not open" error (notOpenErr) and a driver reference number
error (badUnitErr or unitEmptyErr), which indicate the call wasn't successfully
queued by the driver and the ioCompletion routine won't be called. Neither one of these
error conditions makes any sense for the File Manager (which isn't a driver); the File
Manager will always call the completion routine (if any) of a given asynchronous
call. Your program should just ignore the function result of an asynchronous low-
level File Manager call and leave it up to the completion routine or the routine polling
ioResult to check for and handle any errors that may have happened on the call.
Q Many of the new File Manager calls are just HFSDispatch with new selector codes.
How do I check whether a given selector is implemented? An example of a new File
Manager call is GetVolParms. Currently I don't check, I just read the result code. It
seems to be OK. How should I interpret the response from Gestalt when called with
gestaltFSAttr? As I read it, gestaltFullExtFSDispatching tells me that all the calls are
available. Are there times that only a few of them are available? PBHGetVolParms
seems to be available at all times anyway. Where do I find more info on the workings of
HFSDispatch? In general I would appreciate some more info on the compatibility issue.
A There are two issues. One is that not all versions of the File Manager support all
calls. The other is that even if the File Manager supports the calls, individual volumes
may not.
The first issue is addressed by Gestalt's gestaltFSAttr selector. Before System 7,
HFSDispatch supported a fixed range of selectors. The result was that some advanced
file services were unavailable, even though the volume would support them. A good
example is PBCatSearch. If you mount an AppleShare 3.0 or FileShare volume under
System 6 with the AppleShare 3.0 Chooser extension, the volume will report via
PBHGetVolParms that bHasCatSearch is true. But if you try to make the call, you'll get
back a paramErr because HFSDispatch doesn't know about the CatSearch selector.
System 7 doesn't restrict the range of HFSDispatch selectors. For external file
systems, this means it's up to the external file system to determine whether it can
handle the selector and to return an appropriate error if it cannot. This is the meaning
of the gestaltFullExtFSDispatching flag. If it's true, there are no limitations on the
range of selectors.
The second problem is that even though HFSDispatch won't limit the range of
selectors, the volume may still not support the call. To turn the previous example
around, making a PBCatSearch call in System 7 to a pre-AppleShare 3.0 volume will
result in an error because the volume doesn't support the call.
The best way to determine whether a volume supports a feature is to use
PBHGetVolParms. This can return most of the information you need about advanced file
system calls. Unfortunately, there can be problems even with that. For example, when
the user turns file sharing on and off, the bHasPersonalAccessPrivileges flag can
change. So you can't just test attributes once and assume they'll never change.
As far as knowing whether PBHGetVolParms is available, this is not a new call. It's
documented in Chapter 21 of Inside Macintosh Volume V. The way to check for it is to
simply call it and if you get back a paramErr, it's unsupported (page 387). This
seems to be what you're doing, so you should be safe.
To summarize, there's no guaranteed way to know if a particular selector will work
(but it should never crash, just return paramErr). The right sequence of steps is to
first check to see if the HFS supports the full range of calls, then check for specific
features using PBHGetVolParms. And in any event, you should always check for errors
and be prepared to take appropriate action. A good example of how to do this can be
found in the January 1992 version of the Macintosh Technical Note "Searching
Volumes--Solutions and Problems" (formerly #68).
Q How does Developer Technical Support manage to answer so many difficult questions so accurately?
A We swear by the Magic 8-Ball as a technical reference. Not only is it convenient,
user-friendly, and available at your local toy store for less than ten dollars, but it's
guaranteed 100% correct. This way, we manage to answer all questions quickly and
accurately and still leave time for playing Spaceward Ho!
Q What's the purpose of the MacApp 'mem!' and 'seg!' resources, and where does the
documentation for these resources exist?
A The 'mem!' resource allows you to change MacApp's memory allocation reserves in
various ways. Each contains three numbers: the amount to add to the temporary
reserve, which is used for system allocations such as system resources and temporary
handles; an amount to add to the permanent reserve, which is used by you for your
memory allocation; and an amount of stack space. Having multiple 'mem!' resources
causes their values to be summed; in this way, you can create a "debugging" 'mem!'
resource that gives you extra space and delete it when you produce a non-debug
version. This is discussed in the MacApp 2.0 General Reference, in Chapter 3.
The 'seg!' resource is used to reserve space for code segments. If the Macintosh ever
tries to load a code segment but fails due to lack of memory, it will crash. Thus,
MacApp keeps a store of memory solely for loading code resources. It sizes this
reserve by adding together the sizes of the segments named in the 'seg!' resource. One
way to do this would be to just name all the segments, so that you know there's room
for them all; however, this would be wasteful, because many segments are often
unused (your printing code, for example). So what you do is name only those segments
that represent the largest code path you can have--the calling chain that would
require the largest set of code segments to be loaded at any time. This is also described
in Chapter 3 of the MacApp General Reference. In contrast, 'res!' names segments that
must be resident all the time; they're actually loaded and made resident, as opposed to
the 'seg!' segments, which are used only to calculate how much memory should be
reserved for segments in general.
Q I've been thinking of shutting down the System 7 Finder. Is this a cool thing to do in
my application?
A We normally recommend that you don't quit the System 7 Finder application.
Nevertheless, there may be a few good reasons to shut down the Finder. For example,
the Installer (the only application Apple ships with a good reason to do so) sometimes
needs to shut down the Finder and all other applications to make sure system resources
aren't being used while they're being updated by the Installer.
If you find yourself in a situation where you need to shut down the Finder, you should
know about a few things:
Q My Balloon Help message doesn't appear when I use a 'TEXT' resource in a static
window as the message in the balloon, following string resource examples in Inside
Macintosh Volume VI and modifying the code to indicate 'TEXT'. Why doesn't this work?
A While using 'TEXT' resources in Help Manager balloons is a way to provide stylized
text, it doesn't mean that strings longer than 256 are possible. In fact, strings up to
only 239 characters in length are valid. When string lengths are greater than 239 the
Help Manager takes a short- circuit return and no balloon is displayed. To work
around this limit, you can draw a picture with the text you want to display and then
use the picture in the Help Manager balloon.
Q My TrueType font has all 256 characters defined with a unique glyph. I've been
unable to draw the $20 (space) character. DrawChar, DrawText, DrawString, and
DrawJust all ignore this character in the font and draw a blank character. How can I
draw it?
A Unfortunately, the problem with the space character not being drawn is hard-coded
into the text-drawing routine in the core of QuickDraw. ASCII 32 is always "optimized
away," regardless of the font being used or of the particular circumstances. The only
workaround is to put the corresponding character elsewhere in the ASCII character
encoding (or, if this isn't possible, to use an additional font).
You're lucky that TrueType fonts always render the ASCII code 13 (carriage return)
if it has a glyph in the font; for bitmapped fonts, if the character drawing happens
with scaling, or with foreground/background colors different from black/white, even
the CHR(13) drawing is optimized away.
Q After connecting to a remote network via AppleTalk Remote Access (ARA) I can call
PGetAppleTalkInfo and it returns the proper zone name. However, after disconnecting,
PGetAppleTalkInfo still returns the remote network's zone name instead of "*" or
nothing as I would expect. Is there some period of time I should wait before expecting
the zone name and network number to return to zero (no internet)?
A This is, in fact, a bug with ARA version 1.0. Apple is investigating the problem and
there will be a fix in a future release. An easy workaround is to check the GetZoneList
or GetMyZone call to see if it returns any zones.
Q My application opens a number of resource files. If my 'hrct' resources aren't in the
most recently opened resource file, I get an error -192 (resource not found) from
HMGetIndHelpMsg. Is this a Help Manager bug?
A Your 'hrct' resources get loaded only from the most recently opened resource file
because that's where the Help Manager is looking for them. The Help Manager uses
Get1Resource to get 'hrct'-type resources to avoid Resource Manager conflicts with
other resources. This is simply a behavior of the Help Manager. To use
HMGetIndHelpMsg properly, call UseResFile with the refNum of the file containing the
'hrct' before you call the Help Manager. If the 'hrct' is stored in your application
resource fork, you can use HomeResFile or CurResFile (at the start of your program
before you've opened any other resource files) to get the refNum of the application
resource file.
Not all Help Manager resources are treated this way, due to the design of the
Macintosh Toolbox; 'hdlg' resources, for example, are loaded using GetResource so that
things like Standard File can have common help throughout all applications.
Q We're having problems with the GetScrap function in our desk accessory. After a
user opens our DA, when we call GetScrap to get any text from the Clipboard, GetScrap
returns -102 (no requested type in scrap). After once (or more?) through the event
or SystemTask loop, the scrap suddenly shows up. What's causing this?
A The reason for the trouble you're having with desk accessories and GetScrap is that
you're looking for the converted scrap at the wrong time in the process. According to
the MultiFinder documentation (Programmer's Guide to MultiFinder and Inside
Macintosh Volume VI), an application is supposed to convert its private scrap and
write it to the public scrap when it receives a suspend event. When the system opens
your DA, it immediately sends it an Open message; the application hasn't received its
suspend event yet. You have to wait until the scrap has been converted. This, for a DA,
should occur at the first null event, and for applications, when you get a resume event.
Q QuickTime is a joy! But I've run aground with SetMovieRate. I'm trying to change the
rate at which a movie plays back, but if I call SetMovieRate the movie starts playing
immediately, the controller goes wild, and the next time I hit the play button it ignores
the previous rate. How can I control my playback rate?
A SetMovieRate takes effect immediately; that's why the movie starts playing as soon
as you make the call with a rate other than zero. Also, calling SetMovieRate behind the
controller's back can only cause confusion because you're changing the state of the
movie without letting the movie controller know about the change. Note that in normal
operation the movie controller plays back movies at the standard speed, rate = 1; this
is the current behavior. It's possible that in a future release the movie controller will
use the rate the movie was saved with or the one set with SetPreferredMovieRate.
A little-known fact is that the standard controller does contain a primitive mechanism
for controlling the rate of playback. If you hold the Control key down and then click the
stepping buttons, you can, for example, play the movie backward. Furthermore, if you
hold the mouse button down you'll get a slider control that does let you play the movie
at different rates backward or forward.
The slider provided by the standard controller isn't intended to set the rate, so if you
play once at low speed the rate doesn't stick and, as you've found, the next time you
click the play button you go back to the normal speed. If you need the selected rate to
remain for the session, you'll have to provide your own method of selection.
Once you know your desired speed, you'll need to provide your own filter procedure
and install it calling MCSetActionFilter. Upon receiving any mcActionPlay actions for
rate changes, you'll need to call SetMovieRate to set the movie in motion at the desired
rate (and return TRUE). Using a filter procedure is the proper way of doing this
because the controller can keep in sync with the actions even though it's your code that
actually affects the action. Note that you'll have to do some extra work to mimic the
normal behavior of the standard controller. For example, when you're at the end of the
movie and the user hits the play button, the controller goes back to the beginning and
plays the movie. Your filter proc has to do the same when playing back the movie at a
rate different from the normal. A different behavior will confuse the user.
For details on filter procedures, controller actions, and the movie controller in
general, see the "QuickTime Components" chapter of the QuickTime Developer's Guide .
Q How does the Magic 8-Ball achieve its high level of technical accuracy?
A There are two theories on this: The first is that the Magic 8-Ball picks an answer at
random and then alters reality to fit the answer it has picked. For example, if you
were to ask it "Am I a millionaire?" it might pick "Signs point to yes" at random. Then
it would either have to warp reality so that you actually would have a million dollars
or, more likely, warp your memory of the question so that you would think you'd asked
"Is Elvis still alive?" The other theory is that it's just magic.
Q I'm having trouble with PBGetCatInfo returning old data to my application. For
example, if I change a file label using the Finder Label menu and then run my
program, which calls PBGetCatInfo, the fdFlags field in the FInfo record returned
doesn't reflect the change. I've tried calling PBFlushVol before I do this; the file isn't
open, so there's no way to call PBFlushFile. However, restarting the Macintosh or
changing the file's name causes PBGetCatInfo to work correctly. What's going on and
how do I get around it?
A The Finder caches much of the "Finder information," including things like the color
coding information users can set with the Finder Label menu and the view position of
objects in folder windows. Changes to the Finder information are cached until the
folder that contains the objects that were changed is closed (which happens at system
restart or shutdown time) or until some noncached change is made to the object (for
example, the file is renamed). The Finder caches what it considers Finder-specific
information to cut down on the number of disk accesses it must make. (For example,
rearranging the object view in a window would be very slow on floppy disks if the
Finder wrote to the disk every time the user drags a group of objects around.) Since in
most cases no other applications should care about the state of the Finder information,
this normally doesn't cause problems. There's no workaround for this behavior in the
current implementation of the Finder.
Q The Macintosh QuickDraw routine ObscureCursor hides the cursor until the next
time the mouse is moved, but it isn't affected by HideCursor or ShowCursor. Our
application needs to use ObscureCursor while the user is typing but needs the cursor
to be visible after no typing has occurred for a short period. How do we "undo"
ObscureCursor, since we can't rely on the user to move the mouse?
A The only way (besides actual mouse movement) to make an obscured cursor visible
again is to convince the system that the mouse has moved. There's no really good way to
do this via Toolbox calls, so you're going to have to do it the hard way and simply
update the low-memory cursor information to tell the system the cursor moved (even
though you don't need to update the actual position).
To tell the system the cursor has changed location, simply set the crsrNew flag (a
byte located at $08CE) to 1. When the system sees this byte is 1, it will assume the
cursor has moved and redraw the unobscured cursor at the appropriate place (where
it was all along), and reset CrsrNew, waiting for the mouse to move again.
Q In System 7, I want to place my user's preferences file in the Preferences folder in
the System Folder, but I can't seem to get the Preferences folder's directory ID and
other information so that my file will appear there! Also, how do I get to that folder if
the user changes the names of the System Folder and Preferences folder? And once the
user's preferences file is there, am I assuming correctly that the best way to find it
again is to make an alias record to track the file ID?
A System 7 introduced the routine FindFolder for locating the Preferences folder.
Just make this call:
err := FindFolder (kOnSystemDisk, kPreferencesFolderType,
kCreateFolder, prefVRefNum, prefDirID);
If FindFolder returns noErr, prefVRefNum and prefDirID will contain the vRefNum
and dirID of the Preferences folder, which can be used later with HCreateResFile,
HOpenResFile, PBHGetFInfo, and other File Manager calls to locate your preferences
file. If a Preferences folder doesn't already exist, the kCreateFolder parameter
instructs FindFolder to make one and return the vRefNum and dirID of the new folder.
FindFolder is documented in Chapter 9 of Inside Macintosh Volume VI, under "The
System Folder and Its Related Directories." Although FindFolder is implemented only
in System 7, if you're using MPW 3.2 (or the current THINK compilers) glue is
automatically included in your compiled code, making it safe to call FindFolder in
System 6. The glue checks whether FindFolder is available and, if it isn't, returns the
System Folder's vRefNum and dirID for the kPreferencesFolderType selector. Use the
System Folder values as the location for the preferences file in System 6.
If you're not using a development system that provides the FindFolder glue, your code
should check the FindFolder Gestalt selector gestaltFindFolderAttr to see if FindFolder
is available. If FindFolder is available, call it. FindFolder is defined as
FUNCTION FindFolder (vRefNum: INTEGER; folderType: OSType;
createFolder: BOOLEAN; VAR foundVRefNum: INTEGER;
VAR foundDirID: LONGINT): OSErr;
INLINE $7000, $A823;
If FindFolder isn't available, call SysEnvirons to find the System Folder's working
directory reference number, call PBGetWDInfo or GetWDInfo to convert that number
to a true vRefNum and dirID, and use those System Folder numbers for the location of
the preferences file. Example code for this is in the Q&A stack, under Operating
System:File System:Code for identifying vRefNum and dirID of Macintosh System
Folder.
To locate the Preferences folder, follow the steps described above rather than trying
to keep an alias of the Preferences folder or of the preferences file. However, if there
are any other files in the System Folder that the application depends on (such as
dictionaries) those should be tracked with aliases, stored as 'alis' resources in the
preferences file. See Chapter 27 of Inside Macintosh Volume VI for information on
using aliases.
Q I recall reading that QuickTime includes an implementation of the Alias Manager for
System 6, but I haven't found any precise description of what's included. Is it a bare
minimum to support QuickTime? Or is the full Alias Manager there? Also, is there any
way I can use the FSSpec interface to the File Manager, or must I revert to the System
6 interface?
A When QuickTime is installed, most of the Alias Manager is available in System 6,
with these exceptions:
To summarize, in System 6 the Alias Manager doesn't handle relative aliases, multiple
volume searches, "searchMore" searches, and network volume mounting. On the bright
side, nearly all calls are present. Aliases created in System 6 are compatible with
System 7 aliases, and aliases created in System 7 will work in System 6.
Unfortunately, QuickTime doesn't currently install an Alias Manager Gestalt selector,
since it's only a partial implementation. You can check for the Alias Manager using
Gestalt and, if it isn't present, look for QuickTime (using Gestalt); if QuickTime is
present, assume you have an Alias Manager, subject to the limitations listed above.
QuickTime also makes extensive use of the FSSpec data structure introduced in the
System 7 File Manager. Nearly all the FSSpec calls are available in System 6 when
QuickTime is installed. The following calls are available in System 6, and should
behave as documented for System 7: FSMakeFSSpec, FSpOpenDF, FSpOpenRF,
FSpCreate, FSpDirCreate, FSpDelete, FSpGetFInfo, FSpSetFInfo, FSpSetFLock,
FSpRstFLock, FSpRename, FSpCatMove, FSpOpenResFile, FSpCreateResFile, and
FSpGetCatInfo. FSpExchangeFiles isn't available when using the QuickTime System 6
version of the FSSpec calls.
Again, the Gestalt selector for the FSSpec calls isn't installed when QuickTime is
there. This means that the gestaltFSAttr Gestalt selector may not be present, and
gestaltHasFSSpecCalls may not be set, even if gestaltFSAttr is present.
Q I would like to implement the preview/thumbnail feature in the Standard File dialog,
just like the extension included with QuickTime. Is that code available separate from
QuickTime? If not, could I at least get information on how the preview is created?
A To implement your own preview/thumbnail feature, simply duplicate the Standard
File dialog, add the necessary 'DITL' resources, and install a custom filter procedure
for handling preview commands. On the System 7 CD there's an example,
StdFileSample, that shows exactly how to create a custom file dialog. The Macintosh
Technical Note "Customizing Standard File" (formerly #47) describes how to do this
as well. For generating and displaying the preview, you can use the following
PreviewResourceRecord, found at the end of the ImageCompression.h file:
struct PreviewResourceRecord {
unsigned long modDate;
short version;
OSType resType;
short resID;
};
typedef struct PreviewResourceRecord PreviewResourceRecord;
typedef PreviewResourceRecord *PreviewResourcePtr, **PreviewResource;
This is the format for the 'pnot' resource, which defines the preview for the movie
file, usually pointing to a 'PICT' resource. It's all you need to generate
QuickTime-compatible preview without using QuickTime.
Q You guys don't really use the Magic 8-Ball to answer programming questions, do
you?
A Reply hazy, try again.
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; our thanks to all.
Special thanks to Jim "Im" Beninghaus, Neil Day, Matt Deatherage, Tim Dierks, Steve
Falkenburg, C. K. Haun, Dave Hersey, Rich Kubota, Scott Kuechle, Edgar Lee, Jim
Luther, Joseph Maurer, KevinMellander, Jim Mensch, Guillermo Ortiz, Dave
Radcliffe, Greg Robbins, Eric Soldan, Bryan "Stearno" Stearns, Forrest Tanaka, and
John Wang for the material in this Q & A column. *
Have more questions? Need more answers? Take a look at the Dev Tech Answers
library on AppleLink (updated weekly) or at the Q & As on the Developer CD Series
disc, or ask a Magic 8-Ball.*