Winter 92 - MACINTOSH Q & A
MACINTOSH Q & A
MACINTOSH DEVLOPER TECH SUPPORT
Q If I send Apple events to myself and specify kAEQueueReply to AESend, the event doesn't get put in the
queue as I requested. It shows up immediately in the reply parameter. According to Inside Macintosh, if I
specify kAEQueueReply I should treat the reply event as undefined. Please help; my application falls apart
because it never receives the event it's supposed to. If this is a bug, will the behavior be changed in the
A This isn't a bug; it's an undocumented "feature" of the Apple Event Manager (AEM). If you
send an Apple event to yourself, the AEM directly dispatches to the handler you've installed for
that event. So Apple events you send to yourself don't come in through WaitNextEvent. This
means that if you reply to an Apple event you sent yourself, your 'ansr' handler will get called
This was not an arbitrary decision, though it can have some confusing ramifications for an
application. Two factors influenced the decision--the first minor, the second major:
- Speed. The AEM has all the handlers for your application in a hashed table, and can
dispatch very quickly to them, so for performance reasons direct dispatching was
- Event priorities and sequencing. Apple events have a lower priority than user-generated
events (keystrokes, clicks); they come in right before update events. This created a
potentially serious problem for applications that sent Apple events to themselves.
If all Apple events came through the event loop, you could easily create the following scenario:
1. The user selects a menu item, the application sends an Apple event to itself in response, and
this Apple event requires a reply or will cause other Apple events to be sent.
2. The user clicks the mouse in an application window.
The mouse click has a higher priority than the reply or any Apple events that are sent in
response to the first Apple event, and gets posted ahead of the Apple event in the event queue.
This means that the mouse click happens and conceivably changes the current context of the
application (perhaps switching windows, for example); then when the Apple events sent by the
menu item handler are processed through the queue, the application state is not the same as it
was when the menu selection was made, and the menu selection may be totally inappropriate
for the current configuration.
So, to prevent a loss of sequencing, the AEM directly dispatches. Any non-Apple events that
happen while you're sending and processing an Apple event to yourself will be queued and
won't interrupt the Apple event process you've initiated. What this means in the case you're
describing is that queued replies don't happen when you're sending to yourself. The AEM will
directly dispatch to your 'ansr' handler, bypassing WaitNextEvent processing of Apple events to
prevent any other events from breaking the chain of Apple events you may be processing. This
isn't a major problem, but it's something you need to be aware of if you're expecting some
other events to be processed before you get a reply or other Apple event.
Q Under System 7, but not System 6, HiliteMode doesn't work when the foreground and background colors
are similar. Is this a bug?
A Yes, it's a bug. The problem you encounter exists whenever the background and foreground
color map to the same color table index. If the foreground color is the same as the background
color, highlighting is ignored. Therefore, you should always make sure the foreground and
background colors are different when using HiliteMode.
Q When my hardware device sends data to a Macintosh at 57.6 kilobaud, characters can get lost if
LocalTalk is on and a file server is mounted. Does Apple know about the problem? Is there a solution?
A The coherency of a standard serial connection is not guaranteed at any baud rate. Guaranteed
delivery requires more complicated protocols like those employed by AppleTalk or by file
transfer protocols like Kermit. At high baud rates, particularly over 19.2 kilobaud, a Macintosh
serial connection may not be reliable depending on a number of factors.
Every single character that's sent or received by the Macintosh serial port requires an interrupt
to alert the processor that a character is available at the receiver or that the transmitter is ready
to send a character. A nasty drawback of interrupts is that they can be masked--equal or higher
priority interrupts may be in service or other pieces of code running on the machine can disable
interrupts altogether. If the period of time interrupts are not serviced becomes too great, the 3-
byte receive buffer in the serial chip overflows with incoming data and characters are lost. This
is known as a hardware overrun.
AppleTalk works a little differently. When a packet comes across the network, an interrupt
alerts the processor to that event. AppleTalk code then disables interrupts and polls in the
entire packet without multiple successive interrupts. This is necessary because of the high speed
at which data is received: 230.4 kilobaud. The overhead of processing an interrupt for each byte
of data would be prohibitive.
A "worst case" situation is that a 603-byte packet (the largest possible AppleTalk packet) sent to
the LocalTalk port takes approximately 26 milliseconds to receive. Compare this with
asynchronous serial data transmitted at 9600 baud, which would take only 1 millisecond to
receive. A very realistic situation arises in which 26 bits could be lost during a concurrent
AppleTalk/Serial Device transmission. This possibility is increased when there are routers on
the network, which send out large RTMPs (Routing Table Maintenance Packets).
During the time that interrupts are disabled by AppleTalk, AppleTalk code attempts to poll
regular serial data as well (from the modem port only) to prevent the hardware overrun
problem. Unfortunately, at very high serial baud rates there may not be enough time to do
both; characters may be lost anyway.
This same loss of characters may also occur in conjunction with the Sony driver. If a disk is
inserted that requires special attention (like formatting), the odds of losing characters is
increased. The Sony driver has built-in checks like the AppleTalk driver (although not as
frequent). So you can still lose data at high transfer rates if a disk is inserted during the transfer.
The character dropout also occurs on systems that aren't currently running AppleTalk but are
receiving serial transmissions from high-speed devices (57.6 kilobaud) and are performing CPU
tasks that require a high amount of memory access (such as a CPU like the Macintosh IIsi or
IIci running on-board video in 8-bit mode, or a CPU using virtual memory).
This is simply a performance problem, asking the machine to process more data over two
separate ports than the processor speed and hardware architecture can allow. Any number of
factors affect serial performance at high baud rates. Turning off AppleTalk helps. Turning on
32-bit addressing helps because it reduces interrupt handler overhead. Turning on VM hurts
performance for the opposite reason. Running on a faster machine helps. Running on a
Macintosh IIfx or Macintosh Quadra 900 with a serial I/O Processor (IOP) helps a lot because
the IOP handles the serial port regardless of whether the main processor is busy doing
There is, however, a way to ensure reception of high-speed serial data without character loss--
through the use of a Serial NB card or a third-party NuBus TM card with a dedicated processor
necessary to provide higher speeds. These cards in essence operate as dedicated port-handling
circuitry. They're able to perform necessary buffering while the processor is servicing other
interrupts. This is the reason that network cards such as EtherTalk and TokenTalk can
accomplish transactions without data loss; they do at least some of their own buffering until
being serviced to avoid interference with other operations such as receiving serial data. Alternatively, you may want to develop a custom card yourself that exactly fits the needs of your
product. In this case you should look into the Macintosh Coprocessor Platform (MCP) and
Apple Real-Time Operating System Environment (A/ROSE) as a possible basis of this line of
development. Development packages for both these products--the Macintosh Coprocessor
Platform Developer's Kit (#M0793LL/B) and the A/ROSE Software Kit (#M0794LL/B)--are
available from APDA.
Q How can I make FSSpec file information comply with what was an SFReply information block? Is there
a way to convert FSSpec information--as passed, for example, via an Open Documents Apple event--to
a vRefNum as understood by an SFReply record? We want to keep our tried-and-true non-System 7 file
management logic and convert from FSSpec to SFReply-type format.
A Not wanting to make a good bit of file system code obsolete is understandable; however, while
it's unlikely that Apple will dispense with support for old SFGetFile or SFPutFile functions in
the near future, the use of SFReply-style data structures in internal calls has no development
The vRefNum field of the SFReply record was originally (in Inside Macintosh Volume II days) a
volume reference number; later, with the creation of HFS in 1986, it became a working
directory reference number for purposes of backward compatibility. In HFS, a file or directory
entity on a volume is specified with a volume reference number, a directory ID, and a name. An
FSSpec contains this latter information.
Converting from FSSpec to SFReply requires that your application manage the manipulation of
working directory entities, which has disadvantages from the point of view of the system and
compatibility. There are several difficulties with working directory references:
- There's a system-wide limit on their number.
- If you have a working directory reference to which no file buffers are open and some other
application closes that working directory without your knowledge of it, your internally
stored reference number is invalid and you have no way of knowing about it.
- The documentation about where, when, and how to close a working directory is somewhat
- An FSSpec can refer to either a file or a directory while an SFReply can refer only to a file.
Developer Technical Support urges you to take the time to remove dependencies on SFReply
data structures as soon as is feasible.
Q Can I add a media to a QuickTime movie that is not video or audio? If so, is there anything special I
need to do to add text notes that can potentially accompany each frame in my "movie," which can follow
the video frames if a user edits the movie in any way?
A QuickTime version 1.0 allows for only video and sound media. There's no way to install your
own type, even in a case so obvious as the one you mention. Adding other media types is a high
QuickTime priority and is likely to make it in a future release, but currently there's no
mechanism to do it.
Q Inside Macintosh Volume V (page 445) states that SGetCString automatically allocates memory for
holding the requested string. Does this mean that repeated calls to SGetCString will eventually exhaust
memory and, if so, what's the correct way to release the memory?
A SGetCString automatically allocates memory (via NewPtr) for holding the requested string. It
copies the string into that pointer and returns the pointer in spResult. You need to call
DisposPtr on spResult to deallocate the pointer.Q Installing a VBL task doesn't seem to work on Macintosh systems with on-board video. I get the slot
number for a video card by extracting the second nibble of the base address of the screen's pixMap;
however, on-board video computers report that the video card is in slot $B but the video card doesn't seem
to exist in any slot. Is there a better way to determine a video card slot number? Is there any way to
attach a VBL task to on-board video? How can I determine whether the main monitor is using on-board
A You should be getting the slot number for the video from the AuxDCE entry, not from the
base address of the pixMap (Inside Macintosh Volume V, page 424). You'll need to get the
gdRefNum for the desired monitor from the device list ( Inside Macintosh Volume V, Chapter 5).
For example, to install a VBL task for the main screen, do something like this:
GDevHand := GetMainDevice;
IF GDevHand = NIL THEN HandleError
mainGDRefNum := GDevHand^^.gdRefNum;
DCEHand := AuxDCEHandle(GetDctlEntry(mainGDRefNum));
IF DCEHand = NIL THEN HandleError
ELSE retCode := SlotVInstall(@myVBLTask,DCEHand^^.dCtlSlot);
This should work regardless of the kind of video used.
Q When using "-model far," I get the following error from the linker:
### While reading file "HD:MPW:Libraries:Libraries:Runtime.o"
### Link: Error: PC-relative edit, offset out of range.
(Error 48) %__MAIN
(260) Reference to: main in file: xxx.c.o
What does it mean?
A In your Link command, you should put Runtime.o and the object file containing your main
program close together, and as early in the list as possible. This is because %__MAIN (the part
of Runtime.o that actually receives control when your application is launched) uses a PC-
relative BSR instruction to transfer control to your "real" main. (OK, so it's
Q Do all System 7-savvy programs need to run with background processing enabled?
A Yes, System 7-savvy applications should have the SIZE resource's background processing bit
set. (It's not documented explicitly that you need to have this bit set.)
All System 7 Apple event-aware applications need to be background-capable, since there are
many instances where Apple events will come in to you while you're in the background, and
there will be many times (as new applications are developed) when you will not come to the
front to process a series of events; you'll work in the background as a client for another
You don't want to hog a lot of system time when you have nothing to do in the background,
but with the Edition Manager you do need to be able to receive events while you're in the
background. However, you can still be system-friendly when you do this. Here's one way:
When you're switched into the background, set your sleep time to MAXLONGINT and make
sure you have an empty mouse region. This way, you'll be getting null events very rarely, and
you won't be taking much time away from other applications, but you can still react to events
sent to you by other parts of the system. Then when you come forward, you can reset your
sleep time to your normal, low, frontmost sleep. Note that WaitNextEvent is implemented when running System 6 without MultiFinder, but
there's no DA Handler ensuring that DAs receive time. In this case, large sleep values prevent
DAs from receiving timely accRun calls--the Alarm Clock DA stops ticking, for example. A
compromise that doesn't hog too much processing time is to use sleep values only as large as
30-60 ticks for System 6.
Q Is there a way to test whether a particular key is down independently of the event record? My application
needs to check the Option key status before entering the main event loop.
A The call GetKeys(VAR theKeys:KeyMap) returns a keyMap of the current state of all the keys
on the keyboard. The call is documented in Inside Macintosh Volume I on page 259. The Option
key will appear as the 58th bit (counting from 0) in the map. In MacsBug you can see this with
a DM KeyMap, which returns the following:
0000 0000 0000 0004 0000 0000 0000 0000
It's important to understand that the keyMap is an array of packed bits. You need to test
whether the Option key bit is 1 or 0. The key code 58 = $3A is the 58th bit of the keyMap.
This number can be determined from the keyboard figure on page 251 of Inside Macintosh Volume I and pages 191-192 of Volume V. (If in counting the above bits you get 61 instead of
58, remember that the bits within each byte are counted right to left.)
With the above information you should be able to determine the status of any key on the
keyboard within your program without waiting for an event. GetKeys, however, should be
called only for special situations. Normal keyboard processing should be done through events;
otherwise, your application risks incompatibilities with nonstandard input devices.
Q Read calls at interrupt time often result in a "hang," waiting for the parameter block to show "done."
This happens if the interrupt occurred during another Read call. I've tried checking the low-memory
global FSBusy, and that decreases the occurrence of this problem but does not eliminate it. When is it safe
to make the Read call?
A The problem you're experiencing is a common one known as "deadlock." The good news is
that you can always make Read calls at interrupt time! The only requirement is that you make
them asynchronously and provide a completion routine, rather than loop, waiting for the ioResult
field to indicate the call has completed. This will require that you use the lower-level PBRead
call, rather than the high-level FSRead.
The low-memory global FSBusy is not a reliable indicator of the state of the File Manager. The
File Manager's implementation has changed over time, and new entities patch it and use the
hooks it offers to do strange and wonderful things. File Sharing really turns it on its ear. The
result is that when FSBusy is set, you can be sure the File Manager is busy, but when it's clear
you can't be sure it's free. Therefore, it would be best if you ignore its existence.
If you need to have the Read calls execute in a particular order, you'll have to chain them
through their completion routine. The basic concept is that the completion routine for the first
Read request initiates the next Read request, and so on until you're done reading.
By the way, never make synchronous calls at interrupt time (and, contrary to the popular
misconception, deferred tasks are still considered to be run at interrupt time) or from
ioCompletion routines, which may get called at interrupt time.
Q Is there a limit on the values set in the Name Binding Protocol (NBP) interval and count fields when
used with PLookupName and PConfirmName calls? How do the interval and count work? If a device is
not on the network and I send a PLookupName with interval = 20 and count = 20, will I wait 400
seconds before PLookupName returns?
A Since the interval and count parameters for NBP calls are both 1-byte, the values used are
limited to the range of 0-255 ($00-$FF). Here's what the values do:
- interval = retransmit interval in 8-tick units. This value is used to set up a VBL task. A value
of 0 should not be used because that would mean the VBL task would never be executed and
would be removed from the VBL queue.
- count = total number of transmit attempts. Each time the interval timer expires, this value is
decremented by 1. When it reaches 0, the NBP call completes. So if a value of 0 is used, the
packet will be retransmitted 255 times (or transmitted 256 times).
Three things can happen to make the LookupName, RegisterName, or ConfirmName calls
- PKillNBP can be called to abort one of the calls (see Inside Macintosh Volume V, page 519).
- maxToGet matches are returned or the return buffer is filled. Here's how this works: Each
time an NBP lookup reply (LkUp-Reply) packet is received, an attempt is made to add all
the NBP tuples found in that LkUp-Reply packet to the return buffer. If all the tuples
cannot be added to the buffer because there isn't enough room, the call completes with as
many tuples as could fit and the numGotten field will contain the number of matches in the
buffer. If all the tuples from the LkUp-Reply packet are added to the buffer, numGotten
(the number of matches in the buffer) is compared to the value passed in the maxToGet
field. If numGotten is greater than or equal to maxToGet, the call completes and the
numGotten field will contain the number of matches in the buffer. Since the buffer can fill
before maxToGet matches are received and since LkUp-Reply packets can return multiple
tuples, you may get more or fewer matches than you asked for with maxToGet.
- The count is decremented to 0. You can use this equation to determine how long the call
would take to complete this way:
IF count = 0 THEN count := 256;
TimeToCompleteInTicks := count * interval * 8;
The RegisterName and ConfirmName calls always complete after they receive the first LkUp-
Reply packet to their request, so you could look at them as always having a maxToGet of 1
(maxToGet is not one of the parameters for those two calls).
Q Why does System 7 get rid of my 'vers' resources in my desk accessories when dropped into the System
A The System 7 Finder takes over some of the job of the old Font/DA Mover program. The
Font/DA Mover took great pains to keep all resources owned by the DA together with the
driver resource. This is mentioned in Macintosh Technical Note #6, "Shortcut for Owned
Resources," as well as in Inside Macintosh Volume I, page 109.
Under System 7, the 'vers' resource used for Finder information is not owned by the desk
accessory, so when the Finder copies the desk accessory it skips the resources extraneous to the
DA--including the 'vers' resource.
The simplest thing to do is to provide a System 7-ready version of your DA (see Inside
Macintosh Volume VI, page 9-32). The Finder will not strip off resources if the file type is
already 'dfil' when the DA is dragged to the System Folder. You can also provide a version of
the DA in a suitcase for System 6, or you can instruct System 6 users to hold down the Option
key while clicking Open in Font/DA Mover if they want to install your DA.
Q Are CRMSerialRecord's inputDriverName and outputDriverName fields of type StringHandle or are
they Pascal string pointers?
A As shown on page 183 of Inside the Macintosh Communications Toolbox , the CRMSerialRecord
data structure contains two fields, inputDriverName and outputDriverName, declared as type
StringHandle. These two fields are erroneously described as "pointer to Pascal-style string" in
the documentation further down the page. The correct declaration is type StringHandle.
Q How many ways are there to assemble an industry-standard Mr. Potato Head, part number 2250?
A With the standard Mr. Potato Head accessory set, there are 1,139,391,522 different ways to
assemble Mr. Potato Head. Some of our favorite configurations are as follows:
- The demon cyclops Potato Head: assemble as normal, but turn the eyes sideways and tape
sharp objects to his hands.
- The Australian Potato Head: assemble upside down (in Australia, this is known as the
U.S.A. Potato Head).
- The "Gaping Wonder" Potato Head: assemble backwards, using the part storage
compartment as a mouth.
Q What is csCode 100? A control call with csCode 100 seems to come into my block device driver whenever
the Macintosh system fails to recognize the file system on my media. Should my driver specify valid non-
HFS formats such as ISO 9660?
A The csCode 100 you're seeing is a ReadTOC command bound for what the operating system
thinks is a CD-ROM drive. What's happening here is that after deciding your device doesn't
contain an HFS partition, Foreign File Access (FFA) is attempting to identify the file system
residing on that device; looking at the Table of Contents on a CD is one of the ways that it
attempts to go about that. This csCode is documented in the AppleCD SC Developer's Guide, which is available through APDA (#A7G0023/A).
If you remove the Audio CD File System Translator (FST) from your System Folder, you'll
find that the csCode no longer gets issued. The reason is that the ReadTOC call returns
information about audio CDs. Your driver doesn't even have to support this call; if FFA sees a
paramErr (which you should return upon seeing an unrecognized csCode) it knows it can't be
looking at an audio CD.
You needn't worry about adding any support to your driver for ISO 9660 or High Sierra. FFA's
FSTs will just request certain blocks from your driver which contain information that identifies
the disk in question as ISO or HFS.
Q What's the story with RealFont and TrueType? I'm finding that, of the standard System 7 TrueType
fonts, only Symbol and Courier get a TRUE result from RealFont for 7-point.
A You're correct in your observation of RealFont for the 7-point size of certain TrueType fonts.
The explanation is hidden in TrueType Spec--The TrueType Font Format Specification (APDA
#M0825LL/A), page 227.
The font header table contains a lowestRecPPEM field, which indicates the "lowest
recommended pixel number per em," or, in other words, the smallest readable size in pixels. As
it turns out, the Font Manager in its wisdom uses this information for the value it returns from
RealFont. Note that for higher-resolution devices, a point size of 7 does not correspond to 7
pixels; but since the unit "point" is 1/72 inch and the screen resolution is (approximately) 72
dpi, the result corresponds to reality in this case.
The value for lowestRecPPEM can be arbitrarily set by the font designer. We all know that
small point sizes on low-resolution devices never look great, and even less so for outline fonts.
Courier and Symbol have lowestRecPPEM = 6, while the other outline fonts in the system have
lowestRecPPEM = 9. This doesn't mean that Courier and Symbol (TrueType) in 7-point size look better than Times® or Helvetica under the same conditions. It means the font designer
had higher standards (or was in a different mood) when choosing lowestRecPPEM = 9.
Q Is trackbox in the MPW C library broken? It always returns 0 (false).
A Yes, the glue for the MPW C library trackbox is broken. In fact, the glue for many of the
lowercase Toolbox calls is broken. Fixing lowercase glue routines is a never-ending challenge.
This probably won't be fixed; instead, expect to see all lowercase glue routines removed from
future versions of MPW. What does this mean to you? Use only the proper mixed-case
interfaces (the ones spelled just like in Inside Macintosh ) at all times. This also will serve to make
your code smaller and faster, since the mixed-case interfaces make direct Toolbox calls instead
of calls to glue routines in many cases.
Incidentally, in case you're wondering, the C library trackbox doesn't work because the glue
clears a long for the result instead of a word and pulls a long off the stack, so the result is in the
wrong byte of the register on return.
Q After an application in the System 7 Application or Apple menu is selected, sometimes control doesn't
switch from our application to the selected application. What could be wrong and how can I zero in on the
A The symptoms you've described--the process menu not switching layers--is exactly what
happens if you have an activate or update event pending that you're not acting on. Here are
ways that pending activate or update events can be handled incorrectly:
- You're not calling BeginUpdate and EndUpdate (the most likely problem).
- Your application isn't asking for all events.
- Your application has dueling event loops.
- The word in your code that contains the everyEvent constant is trashed (unlikely).
Q I have a problem with Balloon Help for modeless dialogs. The balloons don't show up most of the time
unless the user clicks the mouse over the dialog item of interest.
A The problem you're having is that you're not calling isDialogEvent with null events. The most
likely cause for this is that you're not getting null events, or you have your sleep time way too
high in WaitNextEvent. If you're not getting null events, it's probably due to unserviced update
events in the event queue. If you can't ensure that you'll get null events back from
WaitNextEvent, you must fudge them instead. This way the TextEdit insertion point will blink
properly as well.
Q What's the correct method for a custom MDEF to dim menu items when running under System 7?
What's the preferred method for determining whether to draw in a gray color or paint the items with a
A The proper method for dimming text in menu items is to use the grayishTextOr transfer mode
when drawing text. This is documented on page 17-17 of Inside Macintosh Volume VI and is
what Apple uses. This mode takes into account both color and black-and-white screens. A
simple method for dimming nontext items is to set the OpColor to gray and then draw the
nontext item in Blend mode.
Q Under System 7 my filter procedure for displaying invisible data files no longer works. How can I use
Standard File to display the names of invisible files of a specific type under System 7?
A System 7 can show invisible files in the standard SFGetFile dialog box; however, not all System
6 Standard File package calls are handled the same in System 7. When using invisible files under System 7, you should perform type filtering within a filter proc
and not with the typeList field of the SFGetFile call. System 7 no longer allows a typeList for
detecting invisible files. The actual check for invisible files of a particular type or types should
be done within the file filter proc.
The SFGetFile call below displays only folders and invisible 'TEXT' files in the standard
SFGetFile dialog box. With the numTypes parameter set to -1, all types of files will be passed
to the filter proc.
SFGetFile( where, "", myFilterProc, -1, typeList, nil,
In this example, the filter proc's return value depends on the file's type and Finder flags.
pascal Boolean myFilterProc( fp )
if ((fp->ioFlFndrInfo.fdFlags & fInvisible) &&
(fp->ioFlFndrInfo.fdType == 'TEXT'))
Q The System 7 Help, Keyboard, and Application menus at the right of the Macintosh menu bar don't
have text titles that can be included in a command string in the way that "File" or "Edit" can be. Do
these menus always have the same menu ID?
A The menu ID numbers of the Help, Keyboard, and Application menus are always the same, so
the menus can always be identified by their IDs:
kHMHelpMenuID = -16490;
kPMKeyBdMenuID = -16491;
kPMProcessMenuID = -16489;
Q Do String2Date and Date2Secs treat all dates with the year 04 to 10 as 2004 to 2010 instead of 1904
A Yes, the Script Manager treats two-digit years less than or equal to 10 as 20xx dates if the
current year is between 1990 and 1999, inclusive. Basically, it just assumes that you're talking
about 1-20 years in the future, rather than 80-100 years in the past. The same is true of two-
digit 9x dates, when the current year is less than or equal to xx10. Thus, in 2003, the date
returned when 3/7/94 is converted will be 1994, not 2094. This is all documented in Macintosh
Worldwide Development: Guide to System Software , available from APDA (#M7047/A).
Q Is there a universally recognized wildcard character for the Macintosh, like the "*" in the MS-DOS
world? Furthermore, for Boolean logic, should my application accept Pascal syntax (such as .NOT.,
.AND., .OR.), C syntax (such as !, &&, ||), or still another convention? My users aren't programming
A First, see if there's a friendlier way to implement the wildcard's function. Take a look at System
7 Finder's Find command, for example. If you find wildcard use is necessary, "*" is common,
though for file searching any character other than ":" can be used in an HFS filename.
As for Boolean operators, nonprogrammers prefer a syntax that matches English as closely as
possible, so AND, OR, and NOT are better than their C counterparts. However, user testing
indicates that the most intuitive, user-friendly way to put Boolean search criteria on a command
line is to bring up a dialog with pop-up menus used to form an English sentence describing the search (like System 7's Find). If you can make something like this work for your application,
your nontechnical users will love you.
Q When I pass FALSE in the cUpdates parameter to SetPalette, I still get update events to that window
when I modify its palette. What's going on?
A SetPalette's cUpdates parameter controls whether color-table changes cause that window to get
update events only if that window is not the frontmost window. If that window is the frontmost
window, any changes to its palette cause it to get an update event regardless of what the
cUpdates parameter is. When you call SetEntryColor and then ActivatePalette for your
frontmost window, the window gets an update event because it's the frontmost window even
though you passed FALSE in the cUpdates parameter. Another important point is that windows
that don't have palettes always get update events when another window's palette is activated.
Fortunately, system software version 6.0.2 introduced the NSetPalette routine, which is
documented in Macintosh Technical Note #211, "Palette Manager Changes in System 6.0.2,"
and on page 20-20 in the Palette Manager chapter of Inside Macintosh Volume VI. This
variation of SetPalette gives you the following options in controlling whether your window gets
an update event:
- If you pass pmAllUpdates in the nCUpdates parameter, your window gets an update event
when either it or another window's palette is activated.
- If you pass pmFgUpdates, your window gets an update event when a palette is activated only
if it's the frontmost window (in effect, it gets an update event only if its own palette is
- If you pass pmBkUpdates, your window gets an update event when a palette is activated
only if it's not the frontmost window (in effect, it gets an update event only if another
window's palette is activated).
- If you pass pmNoUpdates, your window never gets an update event from any window's
palette being activated, including that window itself.
Q I want to determine whether a disk is locked before trying to mount the volume. When I examine bit 15
of ioVAtrb using PBGetVInfo, as suggested on page 104 of Inside Macintosh Volume II, bit 15 is clear
for a locked volume such as a CD-ROM, but bit 7 is set. Why is this happening?
A The reason for your observed discrepancy is that bit 15 is set for a software lock and bit 7 is set
for a hardware lock. In the case of the CD-ROM there's no software lock but only a hardware
lock, so bit 7 is set and bit 15 is clear. Volumes II and IV of Inside Macintosh both say that "only
bit 15 can be changed" and should be set if the volume is locked. The fact that you can set it
with PBSetVol means that it's a software lock. What the documentation fails to mention is that
using PBGetVInfo you can also check bit 7 of ioVAtrb to see if there's a hardware lock. The
recommended procedure is to first check the hardware lock (bit 7 of ioVAtrb) and then check
the software lock (bit 15 of ioVAtrb).
Q How do we create a "fixed fractional width" font using ResEdit 2.1? I tried setting FontInfo fields such
as ascent and widMax with fractional numbers, but ResEdit refused all noninteger numbers.
A ResEdit doesn't know how to take fixed-point numbers as input, so it assumes the number you
enter for a value like widMax is the integer representation of the fixed-point number. In other
words, ResEdit displays a 16-bit fixed-point number as an integer with 256 times the value of
the fixed-point number actually used by the Font Manager.
To enter the numbers with ResEdit, you'll need to do the conversion yourself. Take an 8.8
fixed-point number and multiply by 256 to get the integer to enter, or take a 4.12 fixed-point
number and multiply by 4096 to get the integer. This rigamarole is necessary because ResEdit wasn't designed to build fonts from scratch. You
may find that third-party tools specifically designed for this task are easier for you. The time
you save in building your width table may be worth the cost of the program.
Q In my Installer script, how can I include the current volume name in a reportVolError alert, as many of
the installation scripts from Apple do?
A The volume name can be included by inserting "^0" as part of the Pascal string passed to the
reportVolError error-reporting clause.
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 Pete "Luke" Alexander, Mark Baumwell, Mike Bell, Jim "Im"
Beninghaus, Rich Collyer, Neil Day, Tim Dierks, Godfrey DiGiorgi, Steve Falkenburg,
C. K. Haun, Dave Hersey, Dennis Hescox, Dave Johnson, Rich Kubota, Edgar Lee, Jim Luther, Joseph Maurer, Kevin
Mellander, Jim Mensch, Bill Mitchell, Guillermo Ortiz, Greg Robbins, Gordon Sheridan, Bryan "Stearno" Stearns, Forrest
Tanaka, Vincent Tapia, John Wang, and Scott "Zz" Zimmerman 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 & A stack on the Developer CD Series disc.*