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 future? 

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 directly.

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 implemented.
• 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 something else.

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 future.

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 ambiguous.
• 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 video? 

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
ELSE
    BEGIN
        mainGDRefNum := GDevHand^^.gdRefNum;
        DCEHand := AuxDCEHandle(GetDctlEntry(mainGDRefNum));
        IF DCEHand = NIL THEN HandleError
        ELSE retCode := SlotVInstall(@myVBLTask,DCEHand^^.dCtlSlot);
    END;

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 "32-bit-almost-everything"!)

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 application.

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 complete:

• 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 Folder icon? 

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 problem? 

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 gray pattern? 

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,
              &reply );

In this example, the filter proc's return value depends on the file's type and Finder flags.

pascal Boolean myFilterProc( fp )
FileParam *fp;
{
    if ((fp->ioFlFndrInfo.fdFlags & fInvisible) &&
            (fp->ioFlFndrInfo.fdType == 'TEXT')) 
        return FALSE;
    else
        return TRUE;
}

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 to 1910? 

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 gurus. 

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 activated).
• 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.*