Q When a request for information is passed to me through an Apple event, the direct
object parameter of my reply event is a descriptor list that includes an AERecord of
my information. When I use AEPutPtr and the AEPutParamDesc, is the data copied or
merely referenced? Should I be disposing of the AERecord and/or the descriptor list,
or should I expect AEProcessAppleEvent to dispose of them?
A Whenever you make one of the AEPutXXXX calls, the Apple Event Manager copies the
data you put into the list, event, or record, so as soon as you make the call you can
dispose of the data you put. Thus, the following is correct:
AEPutParamDesc(&theEvent, keyDirectObject, &theSpec);
AEDisposeDesc(&theSpec);
And so is this:
HLock(myTextHandle);
AEPutParamPtr(&theEvent, keyDirectObject, typeText,
(Ptr)*myTextHandle, GetHandleSize(myTextHandle));
DisposeHandle(myTextHandle);
The only two descriptors disposed of by the Apple Event Manager itself (at the
conclusion of AEProcessAppleEvent) are the original Apple event and the reply Apple
event. So, anything that you create and manipulate yourself should be disposed of by
you when you add it to another Apple event record or when you're done with it. The two
that you don't dispose of yourself are theEvent and reply, which are passed to you, as
in:
pascal OSErr AEXXXHandler(AppleEvent *theEvent, AppleEvent *reply,
long refIn)
This even holds true for AESend. When you send an event, you can immediately dispose
of your copy of the event, as follows:
AESend(&myEvent, nil, kAENoReply, kAENormalPriority,
kAEDefaultTimeout, nil, nil);
AEDisposeDesc(&myEvent);
Q The System 7.1 Digest has a disturbing comment about GetMHandle -- namely that it
was never supported and will no longer work. Is this true?
A This warning is misleading and is being corrected in future release notes. It applies
only to pop- up menus created with the pop-up menu control. Before System 7.1,
after a control was created GetMHandle would return the menu handle for the control,
although it was never documented as doing so. In System 7.1 it was changed so that the
menu would be inserted into the menu list only when the control was getting ready to
pop up the menu and deleted as soon as the control was done with it, so you could no
longer use GetMHandle to retrieve the menu handle. The proper way to get the menu
handle is from the mHandle field of the popupPrivateData structure. The handle to this
structure is in the contrlData field of the pop-up menu's control record.
A corollary is that the pop-up control has always checked to see if the menu is already
in the menu list. If it is, the control doesn't get the menu from the menu resource and
doesn't delete the menu when it's done. You can use this feature, for example, if you
want to create a menu with NewMenu rather than getting it from a resource. In this
case, and all other cases where the application inserts and deletes the pop-up menu in
the menu list itself, GetMHandle can be used to retrieve the menu handle because it's
under the control of the application.
Q I read that Photo CD discs can be read by the AppleCD SC Plus and the AppleCD 150.
Does this mean a plain vanilla AppleCD SC can't read them? Is this a hardware
limitation, or will there be a software fix?
A Apple erroneously reported that the original AppleCD SC could not read
single-session Photo CD discs. This turns out not to be the case; all of Apple's CD-ROM
drives can read single- session Photo CD discs.
Two levels of support are available for Kodak Photo CDs: the ability to read the first
session on the Photo CD itself, and the ability to deal with more than just the initial
session of a multisession CD. The AppleCD 300i is the first CD-ROM player from
Apple to support multisession Photo CDs. For details about both support levels, check
the Tech Info Library on AppleLink.
Q Inside Macintosh Volume V, page 103, says that when a PICT pattern opcode (for
instance, 0x0012) comes along, and the pattern isn't a dither pattern, the full pixMap
data follows the old-style 8-byte pattern. The pixMap data structure shown on page
104 starts with an unused long (baseAddr placeholder), followed by the rowBytes,
bounds, and so on. However, looking at the Pict.r file on the October 1992 Developer
CD, at the same opcode (BkPixPat == 0x0012), the first data field after the old-style
pattern (hex string[8]) is the rowBytes field (broken down into three bitstrings).
The baseAddr placeholder field isn't there. Which is correct?
A The Inside Macintosh Volume V documentation on pages 103-104 is wrong. The
Pict.r file correctly describes the format of the PnPixPat and BkPixPat opcodes. So
there shouldn't be a baseAddr field in the pixMap record of a pattern as stored in the
PnPixPat of a PICT. However, the baseAddr does occur in a 'ppat' resource as described
on page 79. Thanks for pointing out this discrepancy.
Q How do I find the correct time values to pass to GetMoviePict, to get all the sequential
frames of a QuickTime movie?
A The best way to find the correct time to pass to get movie frames is to call the
GetMovieNextInterestingTime routine repeatedly. Note that the first time you call
GetMovieNextInterestingTime its flags parameter should have a value of
nextTimeMediaSample + nextTimeEdgeOK to get the first frame. For subsequent calls
the value of flags should be nextTimeMediaSample. Also, the whichMediaTypes
parameter should include only tracks with visual information, 'vide' and 'text'. Check
the Movie Toolbox chapter of the QuickTime documentation for details about the
GetMovieNextInterestingTime call. For a code example, see the revised SimpleInMovie
on this issue's CD. The routine to look at is called DoGetMoviePicts in the file
SimpleInPicts.c.
Q My routine uses a dialog hook to set and retrieve certain values in new items added to
the default box. Previously, with SFPPutFile, I was able to use a hit on the Save item
to retrieve and save the values. This also works with CustomPutFile unless the
Replace/Cancel dialog box appears, because the dialog hook routines are also called for
it! With the dialog pointer now pointing at the small alert, any reference to expected
items leads to disaster, since they don't exist. Isn't calling the dialog hook routine to
respond to hits in the alert box wrong and therefore a bug?
A Both Standard File and the Edition Manager in System 7 allow you to have control in
your filter when one of the subdialog boxes comes up. You can differentiate between the
main dialog and the subdialogs by looking in the refCon field of the dialog record passed
to you. In Standard File's case, if the dialog is the main dialog, the refCon will be:
/* From StandardFile.h */
/* The refCon field of the dialog record during a modalfilter
or dialoghook contains one of the following: */
#define sfMainDialogRefCon 'stdf'
#define sfNewFolderDialogRefCon 'nfdr'
#define sfReplaceDialogRefCon 'rplc'
#define sfStatWarnDialogRefCon 'stat'
#define sfLockWarnDialogRefCon 'lock'
#define sfErrorDialogRefCon 'err '
This is described in detail on page 26-18 of Inside Macintosh Volume VI, in the
middle of the section that describes all the callbacks and pseudo items for Standard File
under System 7. The main purpose of this is to allow your additional dialog items to
react properly when another dialog box is brought up in front of them, not to allow you
access to the subdialogs. Also, since Standard File has no idea what types of items
you've added to the dialogs, giving you control during subdialogs allows you to change
the look of your subitems, or to keep them active if they need periodic time for any
reason.
Q How do I find the current KCHR resource?
A Here's a method for getting a copy of the KCHR resource currently being used by the
system. This method works for both System 6 and System 7.
{
long keyScript, KCHRID;
Handle KCHRHdl;
/* First get the current keyboard script. */
keyScript = GetEnvirons(smKeyScript);
/* Now get the KCHR resource ID for that script. */
KCHRID = GetScript((short)keyScript, smScriptKeys);
/* Finally, get your own copy of this KCHR. Now you can pass
a proper KCHR pointer to KeyTrans. */
KCHRHdl = GetResource('KCHR', KCHRID);
}
Q When I use CopyBits to move a cGrafPort's portPixMap to another cGrafPort (my
printing port), it works like a charm when background printing is turned on, but
when CopyBits gets called with background printing turned off, the image that prints
isn't the image at all. Why is this happening?
A You should be aware that since you're copying the pixels directly from the screen,
the baseAddr pointer for the screen's pixMap may be 32-bit addressed. In fact, with
32-Bit QuickDraw, this is the case. This in itself isn't a problem, since CopyBits
knows enough to access the baseAddr of the port's pixMap in 32-bit mode, as follows:
mode = true32b;
SwapMMUMode(&mode);// Make sure we're in 32-bit addressing mode.
// Access pixels directly; make no other system calls.
SwapMMUMode(&mode);// Restore the current mode.
That's how you'd normally handle things if you were accessing the pixels directly
yourself. Unfortunately, the LaserWriter driver doesn't know enough to do the
SwapMMUMode and instead ends up copying garbage (from a 32-bit pointer stripped
to a 24-bit pointer).
So why does background printing work? Because when you print in the background,
everything is rolled into a PICT, which the driver saves off for PrintMonitor. Since
the driver is using the standard QuickDraw picture bottlenecks to do this, and CopyBits
knows to swap the MMU mode before copying the data into the picture, everything
works great. Later, at PrintMonitor time, the picture is played back. Since the data is
no longer 32-bit addressed, the LaserWriter driver doesn't have to call
SwapMMUMode to do the right thing; it can just play the picture back. The solution we
propose for you is something similar. At print time (before your PrOpenPage call),
call OpenPicture, copy the data from the screen with CopyBits, call ClosePicture, and
then call DrawPicture within your PrOpenPage/PrClosePage loop. That should do the
trick.
Note that copying bits directly from the screen is not something we recommend.
Unless you have no alternative, you should always copy from the original source of the
data instead.
Q Is there a way to read Greenwich Mean Time offsets from the Map control panel?
A There's actually a system-level call to find out where you are. It's a Script Manager
call named ReadLocation (used by the Map control panel), which returns a structure
giving you all the information you need. Here's a description of the call, copied from
MPW 411:
pascal void ReadLocation(MachineLocation *loc)
= {0x205F,0x203C,0x000C,0x00E4,0xA051};
File {CIncludes}script.h
In C:
pascal void ReadLocation(MachineLocation *loc);
pascal void WriteLocation(const MachineLocation *loc);
These routines access the stored geographic location and time zone information for the
Macintosh from parameter RAM. For example, the time zone information can be used to
derive the absolute time (GMT) that a document or mail message was created. With
this information, when the document is received across time zones, the creation date
and time are correct. Otherwise, documents can appear to be created after they're read.
(For example, someone could create a message in Tokyo on Tuesday and send it to San
Francisco, where it's received and read on Monday.) Geographic information can also
be used by applications that require it.
If the MachineLocation has never been set, it should be <0,0,0>. The top byte of the
gmtDelta should be masked off and preserved when writing: it's reserved for future
extension. The gmtDelta is in seconds east of GMT; for example, San Francisco is at
minus 28,800 seconds (8 hours * 3600 seconds per hour). The latitude and longitude
are in fractions of a great circle, giving them accuracy to within less than a foot,
which should be sufficient for most purposes. For example, Fract values of 1.0 = 90º,
-1.0 = -90º, and -2.0 = -180º. In C:
struct MachineLocation {
Fract latitude;
Fract longitude;
union {
char dlsDelta; /* signed byte; daylight savings delta */
long gmtDelta; /* must mask - see documentation */
} gmtFlags;
};
The gmtDelta is really a 3-byte value, so you must take care to get and set it
properly, as in the following C code examples:
long GetGmtDelta(MachineLocation myLocation)
{
long internalGMTDelta;
internalGMTDelta = myLocation.gmtDelta & 0x00ffffff;
// need to sign extend
if ( (internalGMTDelta >> 23) & 1 )
internalGmtDelta = internalGmtDelta | 0xff000000;
return (internalGmtDelta);
}
void SetGmtDelta(MachineLocation *myLocation, long myGmtDelta)
{
char tempSignedByte;
tempSignedByte = myLocation->dlsDelta;
myLocation->gmtDelta = myGmtDelta;
myLocation->dlsDelta = tempSignedByte;
}
Q Did you hear that they had computer music at Clinton's inauguration?
A Yes, they danced to Al Gore Rhythms.
Q What (if at all) is the limitation on the number of files in a folder? In other words,
is there a number N, such that if I have N files in a folder, and I try to Create file
number N+1, I'll get some error?
A In general, the number of files that can be put in an HFS directory is unlimited;
there isn't any point at which you'll receive an error from Create, because new file
description records can almost always be created. The only way you can get a disk full
error back from Create is if the catalog file needs to grow to add your new record and
the disk is full, but this should be extremely rare; even when the disk is full, there's
generally room to create dozens of files or folders before the catalog file will need to be
enlarged, as it's grown in relatively large chunks.
There are, however, a couple of related limits on large numbers of files. Because HFS
allocates space in "allocation blocks," and there can be at most 65,536 allocation
blocks on a volume, there's a limit of 65,536 files that contain data on a volume. If
your disk is full with 65,536 one- block files, you'll probably be able to create more
files (Create will succeed), but no data will be able to be written to them. In reality,
the limit on the number of files is somewhat smaller; the catalog and extents files will
each occupy space. Also, because the allocation block size needs to be an even multiple
of 512 bytes, most volumes won't have a full 65,536 allocation blocks; they'll have as
many as they can, somewhere between 32,767 and 65,536 (except for small
volumes, which may have less). In addition, each fork (either the data fork or the
resource fork) of a file needs to be separately allocated, so each counts as a file for
this calculation.
There's also a practical limit on how many files can be placed in a folder. HFS can
maintain as many files as required in a directory; however, because the index field is a
short, if there are more than 32,767 files in a folder, they can't be enumerated. Thus,
while they can be identified and opened by name, there's no way to index through them
to determine what's in the directory without deleting or moving some of the files.
These limit descriptions apply to HFS only; other file systems may be available on the
Macintosh, such as MFS, MS-DOS, ISO 9660, or virtually any file system via an
AppleTalk Filing Protocol (AFP) translator. These descriptions also don't include
limitations of the Finder, the Standard File Package, or any other intermediaries. The
Finder and Standard File are likely to become quite unusable long before you run into
the limits of HFS. Also, while HFS will continue to function, it wasn't designed for
optimum performance with extremely large numbers of files; for more dire warnings
on this subject, see the Macintosh (Overview) Technical Note "Don't Abuse the
Managers" (formerly #203).
Q In the two-byte script version of our application, we need to insert certain
characters such as "-" and "%" into some of our strings. How can we do this, since
these are obviously only one character long in C?
A All 7-bit ASCII characters (codes less than 127) are maintained as such in all
two-byte scripts. If your routines just concatenate existing (localized) strings and
characters, you don't have to worry about anything. Otherwise, you'll need to call
CharByte ( Inside Macintosh Volume V, page 306, and Volume VI, pages 14-45,
14-114, and 14-124) while walking the bytes in the string.
In the Macintosh (Text) Technical Note "Fond of FONDs," the part about
OutlineMetrics was updated recently to be "two-byte aware." The code fragment there
should help you with strings containing text for two-byte scripts. See also the article
"Writing Localizable Applicatio n s" in this issue.
Q The Icon Utilities routine GetIconCacheData leaves two bytes of garbage on the stack.
This surfaced as a problem for me because it prevented a saved register from getting
restored properly. SetIconCacheData probably has the same problem, since it calls the
same trap internally. I solved the problem by encapsulating GetIconCacheData within
my own static function, like so:
static OSErr _GetIconCacheData( Handle theCache, void **theData )
{
returnGetIconCacheData( theCache, theData );
}
#define GetIconCacheData_GetIconCacheData
I then call GetIconCacheData normally. The #define redirects my call to my static
wrapper function. The extra two bytes on the stack are recovered when the wrapper
function UNLKs and returns. This method has the advantage that the calling code will
still work even after the trap is fixed. Am I correct?
A You're quite correct; this is a bug. Here's the offending code from the source:
EXIT MOVEA.L (SP)+, A0 ; Pop return address into A0
ADDQ.L #6, SP ; Point stack at return value
MOVE.W D0, (SP) ; Put return value on the stack
JMP (A0) ; Return
As you can see, the exit routine is adding 6 to the stack to clear up the input
parameters instead of 8 (handle and handle), so an extra word of garbage is being left
on the stack. Thanks for letting us know about the problem.
Q When I double-click a document that launches my application, the current directory
for the Standard File Package (at location $398 in memory) is set to the directory of
my application and not my document. This seems to be a bug according to the text on
page 3-31 of the new Inside Macintosh: Files manual. Is there anything special I have
to do?
A You're right. The behavior described in Inside Macintosh: Files isn't entirely
correct. It should say that the first time your application calls one of the Standard File
Package routines, the default current directory (that is, the directory whose contents
are listed in the dialog box) is determined by the way your application was launched.
Note that applications that are high-level event aware are passed the list of documents
to open or print in a kAEOpenDocument or kAEPrintDocument Apple event. There's no
Finder information (AppParmHandle will be NIL) and the default directory is the
directory in which your application is located.
Q Sometimes, at the beginning of a PBRead on a serial port, I get back a result code of
-90 in the completion routine. I don't quite know how to handle this error, because I
can't find a -90 result code anywhere. Any idea what -90 means?
A According to the MPW Errors.h interface file, -90 is a BreakRecd result. (The
interface files are always a good place to look for error codes and calls that you can't
find.) The serial driver returns that error to a pending Read if the SCC chip detects a
break condition.
Q Why does MacApp use the Initialize and Free methods instead of the normal C++
constructor and destructor methods?
A MacApp doesn't use constructors for historical reasons. Object Pascal was used in
MacApp 2.0.1, which doesn't have constructors and destructors as part of the language,
and as a result these facilities had to be provided as part of MacApp instead of the
language.
MacApp 3.0 designers tried to achieve backward compatibility with applications
written with older versions of MacApp based on Object Pascal. Because of this, the
designers decided to stay with the Initialize and Free functions rather than just have an
instance of the object declared and destroyed with new and free.
Q Can I use the CompressPicture routine to spool in a source picture from disk by
overriding the QuickDraw proc getPicProc as documented in Inside Macintosh Volume
V, pages 88-89? I'm trying to save the contents of an off-screen GWorld as a
compressed PICT resource. Unfortunately there's no direct way to compress the
GWorld's pixel map to a resource.
A We definitely don't recommend trying to spool in or out the results of
CompressPicture or CompressImage. We recommend doing one of the following instead:
The second suggestion is probably the best idea if you want to keep your memory
footprint small. But much of the decision depends on your application.
Q Our product's sound/video synchronization is way off with QuickTime 1.5; it worked
perfectly with QuickTime 1.0. The video can't keep up with the sound, especially on the
full-screen movies. The movies are playing much slower with 1.5. Isn't QuickTime
1.5 supposed to make movies play faster?
A Your movies probably aren't properly interleaved. When you add sound to a movie
with SoundToMovie, the sound is added to the end of the video data. We recommend that
sound and video be interleaved so that the hard drive doesn't have to spend extra time
seeking between media that store video and media that store audio on a hard drive. The
data handler prefers to be able to sequentially read through a movie file. This is
especially important for slower Macintosh models that don't have the extra CPU and
SCSI access speed to spare.
QuickTime can accommodate for some noninterleaved data by caching an entire sound
track of a movie if small enough. However, the size of a cache is internal to QuickTime
and can't be depended on. It's possible that different QuickTime versions could have
different cache sizes since we've been recommending that video and sound movies be
interleaved. The result could be that the extra disk-seeking time has caused sound and
video to be out of sync for slower machines such as the Macintosh LC.
One way to check interleaving is to resave the movie using Movie Converter (or some
other program that flattens movies) in a flattened format. Movie Converter uses
QuickTime's FlattenMovie call to do this. The steps Movie Converter takes are: choose
Save As, select "Make movie self-contained," and save to a new movie file. This new
movie should play back with correct video and sound sync.
You can actually see the problem if you examine the movie with MovieShop, a program
that lets you deal with QuickTime movies at a movie data level. For example, if you
select the Play information button that's in the window after you open a movie, the
program will display a time graph showing you where the video and sound data are
saved in the continuous data stream. If the movie is interleaved, the green (for video)
and red (for sound) indicators are interleaved. If the movie isn't interleaved, the
green indicators are clumped together in the beginning of the file, and the red
indicators (for sound) are at the end.
The latest version of MovieShop and documentation is available on this issue's CD.
MovieShop and related information are discussed in the article "Making Better
QuickTime Movies" in this issue.
Q How long can a Macintosh filename be on an international system? Our program
currently assumes a maximum filename length of 31. What does the length byte of a
Pascal string signify on an international system -- the actual length in bytes of the
string, the logical length (the number of international characters), or neither?
A The Macintosh file systems -- the flat (MFS) and the hierarchical (HFS) -- have
(reasonable) limitations on the length of filenames. The limits on the lengths refer to
the number of bytes required for the strings. Usually, filenames are represented as
Pascal strings. The first byte of a Pascal string indicates the number of bytes occupied
by the string. In the worst case in a two- byte script, only 15 two-byte characters fit
into a Str31. Compared to one-byte scripts, this isn't so bad, however: two-byte
characters tend to carry much more meaning than two of our familiar one-byte
characters!
Q What is QuickTime for Windows and what hardware do you need to run it?
A QuickTime for Windows makes QuickTime a cross-platform technology that you can
use in both the Macintosh and the Microsoft Windows programs that you're developing.
With it, you can create multimedia programs on the Macintosh and be able to add the
playback of QuickTime movies to any PC application running Microsoft Windows 3.1.
The minimum hardware configuration required for QuickTime for Windows is the
following:
Optional hardware:
The software requirement for running QuickTime for Windows is Microsoft Windows
3.1. To write QuickTime for Windows programs, you must have (in addition to the
QuickTime for Windows Developer's Kit) a development package such as Borland C++
3.1 or Microsoft C/C++ 7.0. The sample QuickTime for Windows executables may be
played under Windows 3.1 immediately following QuickTime for Windows installation
and configuration, without C or C++ being present.
Q I tried to unmount a volume shared with Macintosh File Sharing from my program
as follows: I shut down the file service with the SCShutDown server control call; I call
SCPollServer to make sure the file service is really off (scServerState =
SCPSJustDisabled); then I call PBUnmountVol to attempt to unmount the volume. It
didn't work because PBUnmountVol fails with fBsyErr (-47). I broke on the
_UnmountVol trap because the AppleShare PDS file, where the file server keeps the
access privilege and share-point information for the shared volume, was open. Why is
AppleShare PDS still open when I've turned the file service off? How can I close it and
unmount the volume?
A SCPollServer returns the state of the file service, not the file server application
(in this case, File Sharing Extension is the file server application). When
SCPollServer returns a server state of SCPSJustDisabled, the file service is off;
however, the file server application may or may not still be running. The AppleShare
PDS file will eventually get closed before the file server application quits.
There's an easy way to determine when the File Sharing Extension application has quit
(and thus when the AppleShare PDS file is closed): just use the Process Manager
GetNextProcess and GetProcessInformation calls to find out when File Sharing
Extension is no longer running. The File Sharing Extension application has a
processType of 'INIT' and a processSignature of 'hhgg'. Here's a function you can use to
see if File Sharing Extension is running:
FUNCTION FileSharingAppIsRunning: Boolean;
CONST
FileSharingSignature = 'hhgg'; {Macintosh File Sharing}
VAR
err: OSErr;
myPSN: ProcessSerialNumber;
myPInfoRec: ProcessInfoRec;
BEGIN
myPSN.highLongOfPSN := 0; {Start at beginning of process list}
myPSN.lowLongOfPSN := kNoProcess;
myPInfoRec.processInfoLength := sizeOf(ProcessInfoRec);
myPInfoRec.processName := NIL; {Don't need process name}
myPInfoRec.processAppSpec := NIL; {Don't need process location}
FileSharingAppIsRunning := FALSE; {Haven't found it yet}
WHILE (GetNextProcess(myPSN) = noErr) DO
IF GetProcessInformation(myPSN, myPInfoRec) = noErr THEN
IF (myPInfoRec.processSignature =
FileSharingSignature) THEN
FileSharingAppIsRunning := TRUE; {Found it}
END;
After shutting down the file service, your event loop will need to poll with
FileSharingAppIsRunning because you must give the file server application processing
time to close files, dispose of memory, and perform other shutdown operations. If you
poll with FileSharingAppIsRunning without giving other processes time, File Sharing
Extension will never shut down.
Q I'm having trouble understanding the problems of dealing with potentially infinite
loops in interconnected, distributed applications. Can you help me?
A Please see the next message.
Q I'm having trouble understanding the problems of
dealing with potentially infinite loops in interconnected, distributed applications. Can
you help me?
A Please see the previous message.
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, Brian Bechtel, Cameron Birse, Joel Cannon, Matt
Deatherage, Tim Dierks, Steve Falkenburg, Nitin Ganatra, Bill Guschwan, C. K. Haun,
Dave Hersey, Scott Kuechle, Edgar Lee, Jim Luther, Joseph Maurer, Kevin Mellander,
Martin Minow, Ed Navarrete, Guillermo Ortiz, Dave Radcliffe, Brigham Stevens, Dan
Strnad, Forrest Tanaka, and John Wang 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 in the Dev Tech Answers library on AppleLink.*