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:
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:
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:
Three things can happen to make the LookupName, RegisterName, or ConfirmName
calls complete:
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:
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:
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:
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.*