December 92 - MACINTOSH Q & A
MACINTOSH Q & A
MACINTOSH DEVLOPER TECHNICAL SUPPORT
Q Here's a tidbit I stumbled across in Inside Macintosh Volume VI, page 3-10: the four Dialog Manager
procedures CouldDialog, CouldAlert, FreeDialog, and FreeAlert are no longer supported. I use
CouldDialog, and I happened to notice that it didn't work right when I tested it under System 7, but I
reported it as a bug. Now you tell us that it's not guaranteed to work in System 7. I can't recall a trap
ever becoming suddenly unsupported like this. What's the story?
A The system software engineers felt that CouldDialog, CouldAlert, FreeDialog, and FreeAlert
didn't do much good under System 6, since the Could calls never completely guaranteed that all
dialog items were loaded in. These calls also caused problems in the beta versions of System 7.
Relatively little software uses those traps anymore; like many things in Inside Macintosh Volume
I, they're relics of the days when Macintosh programmers had to deal with desk accessory and
floppy disk support issues. So these calls were simply patched out. In the final System 7, the
traps return without doing anything.
Q I can't get the black-and-white version of my lasso-type tool to work correctly with CalcMask and
CopyMask. With CalcCMask it seems to work fine. What could I be doing wrong?
A CalcMask and CalcCMask are similar in that they both generate a one-bit mask given a source
bitmap. With CalcCMask, though, a pixMap can be used in place of the source bitmap; the
seedRGB determines which color sets the bits in the mask image. An easy mistake to make is to
forget that CalcCMask expects a pointer to a BitMap data structure while CalcMask expects a
pointer to the actual bit image. And unlike CalcCMask, which uses bounding rectangles for the
image's dimensions, CalcMask uses the bitmap's rowBytes and pixel image offsets to determine
the bounding Rects for the image. A typical call to these routines is as follows:
BitMap source, mask;
CalcMask (source.baseAddr, mask.baseAddr, source.rowBytes,
mask.rowBytes, source.bounds.bottom-source.bounds.top,
source.rowBytes>>1);
CalcCMask (&source, &mask, &(*source).bounds, &(*mask).bounds,
&seedRGB, nil, 0);
One last thing to note when using CalcMask is that the width of the image is in words and not
bytes. To learn more about these routines, see page 24 of Inside Macintosh Volume IV and page
72 of Inside Macintosh Volume V. Also, the Developer CD Series disc contains a sample,
CalcCMask&CalcMask, that shows how to use these routines.
Q How do I update the color table of my off-screen graphics world without destroying the picture?
A The recommended approach for changing the color table of an existing GWorld involves
calling UpdateGWorld, passing either clipPix or stretchPix for gWorldFlags. When passed
either of these constants, QuickDraw knows to update the pixels of the pixMap image. Even
though the actual image isn't changed, the flags are still needed to remap the pixels to their new
colors.
Q Are there any C++ or C compilation flags that will optimize performance of the Macintosh Quadra
computers? Even when I use the "-NeedsMC68030" flag in MacApp, an investigation of the MABuild
source files reveals that it sets compiler flags only for the 68020 optimization. If Quadra-specific
compilation flags don't exist, do you have any Quadra performance optimization suggestions?
A The current MPW compilers don't have a 68040 performance optimization flag, though
Apple's future compilers will optimize code for the best possible '040 performance. In the
meantime, here are some tips on '040 performance tuning:
- Cache management for the '040 can give you the biggest performance boost. Keep program
loops inside the cache space, and flush the cache as seldom as possible. In most cases you'll
have small loops inside the 4K instruction cache.
- You might get better performance by not calling BlockMove, because the system flushes the
cache when you call it in case you're moving code. If you're moving data, the cache doesn't
need to be flushed, but the system can't tell from the BlockMove call whether you're
moving code or data. Testing will help you determine whether you should call BlockMove
or write your own transfer routine. The new MOVE16 opcode is used by the BlockMove
trap when the system is running on an '040 processor, but because of problems with this
opcode in early '040 processors, it requires special handling. For details, see the Macintosh
Technical Note "Cache As Cache Can" (formerly #261).
- Transcendental functions aren't implemented in the 68040 hardware as they are in the
68881 chip used with the 68020 and 68030. Consequently, the functions are emulated in
software, resulting in slower performance. If you suspect that your floating point
performance is less than optimal, consider modifying your code to use functions supported
by the internal '040 FPU. See the Macintosh Technical Note "FPU Operations on
Macintosh Quadra Computers" (formerly #317) for more information about this
performance factor. Future MPW compiler and library releases will support faster
transcendental operations and floating point-to-integer conversions.
Q In the past we had heard of a problem using calloc and NewPtr in the same program. Is this true?
A There are a few difficulties, which you can deal with if you need to. The primary problem is
that calloc and all the other malloc routines weren't designed for the Macintosh platform.
Macintosh memory management is designed around trying to squeeze as much as possible out
of a limited memory area, which is why handles are the primary storage scheme in a Macintosh;
they can move, and so greatly reduce memory fragmentation. Because the malloc tools return a
pointer, they have to be located in a locked block, so they tend to lead to fragmentation if used
with any other memory allocation calls (such as NewPtr). For this reason, any use of the malloc
suite of allocation calls isn't recommended for Macintosh programs. The only good reason to
use them is if you're porting a large body of code from other platforms; in this case, it may be a
reasonable tradeoff to keep the old allocation code.
You should also be aware that most of the Macintosh malloc routines never free up memory.
When you malloc some space, the routine must first allocate it from the Memory Manager. It
allocates a large block of space using NewPtr and divides it internally for distribution in
response to malloc calls. If, however, you eventually free all the blocks you allocated from this
NewPtr block, the block won't be released to the Memory Manager with the DisposPtr call.
This means that once you allocate some memory with malloc, you won't be able to free it and
then use that memory from a Macintosh allocation call. Thus, if you had two phases to your
program, one of which used the malloc calls extensively and the second which used Toolbox
calls, the second phase wouldn't be able to use memory freed by the first phase. That memory
is still available in the malloc pool, of course; it simply can't be used by NewPtr or NewHandle.
The malloc routines supplied by THINK C work similarly, as described in their Standard
Libraries Reference . Thus, mixing the C and Macintosh allocation routines requires special care.
Q Why do I get error -903 (a PPC Toolbox noPortErr) when I send an Apple event to a running
application with AESend?
A The isHighLevelEventAware bit of the sending application's SIZE -1 resource (and SIZE 0
resource, if any) must be set.
Q Sometimes the Alias Manager mistakes one volume for another. In particular, we're experiencing
problems getting aliases to volumes to work correctly with our AppleTalk Filing Protocol (AFP) server
volumes. Here's how I can duplicate the problem:
- I mount two server volumes from my AFP server: VolA and VolB.
- I use the Finder to create an alias file for each volume.
- I unmount VolA.
- I open the alias file for VolA. However, when I do this, VolB (which is still mounted) is opened.
Is this a bug in the Alias Manager or did we implement something the wrong way in our server?
A As noted in the Alias Manager chapter of Inside Macintosh Volume VI, the Alias Manager uses
three criteria to identify a volume: the volume's name, the volume's creation date, and the
volume's type. If the Alias Manager can't find a mounted volume that matches all three criteria,
it tries again with just the volume's creation date and the volume's type. This second attempt
finds volumes that have been renamed. If that attempt fails, the Alias Manager tries one last
time on mounted volumes with the volume's name and the volume's type. If it can't find a
mounted volume with those three attempts and the alias is to an AFP volume (a file server), the
Alias Manager assumes the volume is unmounted and attempts to mount it.
The problem you're having is probably happening because both volumes have the same
creation date and type. That will cause the Alias Manager to mistake VolA for VolB and VolB
for VolA when it attempts to match by volume creation date and volume type. You can prevent
the Alias Manager from making this mistake by making sure your server volumes all have
unique volume creation dates.
This same behavior can be observed when partitioned hard disks use the same volume creation
date for all partitions. If one partition isn't mounted, the Alias Manager can mistake one disk
partition for another.
Q I'm looking for a Macintosh Toolbox routine that will allow me to turn down the backlight on a
Macintosh PowerBook from within a screen saver to prevent screen burn and save battery life. Is there
such a thing?
A Turning down the backlight won't prevent screen burn. Screen burn can be prevented only by
either shutting the system off or letting the PowerBook enter its native sleep mode.
In an RGB monitor the phosphor that illuminates each pixel is what causes screen burn. By
setting the pixels to black (the phosphor isn't active) or rapidly changing the colors of an RGB
screen (as with a screen saver), you can prevent screen burn. While effective on an RGB display,
setting the pixels to black may actually cause screen burn on a PowerBook. The reason is that all
the PowerBooks have a liquid crystal display (LCD), which can be burned by white pixels, black
pixels, or repeating patterns on the screen over a period of time. For this type of display the
only good way to save the screen is to power it off.
Only the Power Manager has access to the chip that shuts the screen off. After a certain amount
of time, the Power Manager makes the function calls to put the system to sleep. (These calls are
documented in Chapter 31 of Inside Macintosh Volume VI.) At this time the Power Manager
signals the chip to turn the screen off. There's no direct interface between the user and the chip
to achieve this. It's best to let the PowerBook's native screen-saving mechanism (sleep mode,
which shuts off the screen) work as is. This also has the benefit of saving the precious battery
power that would be used by the screen saver.
By the way, if your PowerBook screen has ghost images because you've left it on too long
without going into sleep mode, letting the screen sleep or shutting down your computer for at
least 24 hours will probably make the ghost images go away. Although there's no hard and fast
rule, usually ghost images caused by your system being on for less than 24 hours won't be
permanent if the screen is rested for an equal amount of time. Any ghost images caused by the
system being on for greater than 24 hours may be permanent.
Q How can I call Connect in AppleTalk Remote Access without an existing ARA connection file created by
the Remote Access application?
A This isn't directly possible, because without the ARA connection file your program becomes
tied to the underlying link tool. The file was implemented so that in the future, when there are
different link tools for the different link types, the program will know the link type and tool,
plus associated link-specific data to use. To connect without the ARA connection file requires
knowledge of the link tool data structures used by each individual link tool. Because these may
change, your code may break.
However, there's a roundabout way of calling Connect. It requires that you first establish a
connection using a document created by the ARA application. Next, make the IsRemote call,
setting the optionFlags to ctlir_getConnectInfo (see page 11 of the AppleTalk Remote Access
Application Programming Interface Guide). This will cause the information necessary to create the
remote connection (connectInfoPtr) to be returned. You would then save this connectInfo data
in your application, and when you want to connect sometime later, you would pass this data to
the Connect call (in the connectInfo field).
Q When we allocate space for a new file using AllocContig with an argument in multiples of clump size, we
should be grabbing whole clumps at a time so that file length (and physical EOF) will be a multiple of
clump size. What happens if we truncate a file by moving the logical EOF somewhere inside a clump?
Inside Macintosh says disk sectors are freed at the allocation block level, so we could have a file whose
physical EOF isn't a multiple of clump size, right? Does AllocContig guarantee that the new bytes added
are contiguous with the end of the existing file, or only that the newly added bytes are contiguous among
themselves? If the logical and physical EOFs aren't the same, does AllocContig subtract the difference
before grabbing the new bytes, or do we get the extra bytes (between EOFs) as a bonus?
A You can create a file whose physical size isn't a multiple of the clump size, if you try. When the
file shrinks, the blocks are freed at the allocation level, without regard for the clump size.
Therefore, if you set the logical EOF to a smaller value, you can create a file of any physical
length.
There's no guarantee that the allocated bytes will be contiguous with the current end of the file.
The decisions that file allocation makes are as follows:
- It always attempts to allocate contiguously, regardless of whether you're explicitly doing a
contiguous allocation. (If it can't, it fails rather than proceeding if doing an AllocContig.)
- It always attempts to keep the added space contiguous with the existing space, but it will
forgo this before it will fragment the current allocation request (regardless of whether
you're calling Allocate or AllocContig).
So these are the actions that file allocation will take:
- Allocate contiguous space immediately after the current physical end of file.
- Allocate contiguous space separated from the current physical EOF.
- Fail here if allocating contiguously.
- Allocate fragmented space, where the first fragment follows the physical EOF.
- Allocate fragmented space somewhere on the volume.
You don't get "extra" space with AllocContig. It just does a basic allocation but makes sure any
added blocks are contiguous. PBAllocContig does not guarantee that the space requested will be
allocated contiguously. Instead, it first grabs all the room remaining in the current extent, and
then guarantees that the remaining space will be contiguous. For example, if you have a 1-byte
file with a chunk size of 10K and you try to allocate 20K, 10K-1 bytes will be added to the
current file; the remaining 10K+1 bytes are guaranteed to be contiguous.
Q Inside Macintosh says that ROM drivers opened with OpenDriver shouldn't be closed. However, it seems
that any driver opened with OpenDriver should be closed when the application is done. Should our
application close the serial port after using it?
A As a general rule, applications that open the serial driver with OpenDriver should do so only
when they're actually going to use it, and they should close it when they're done. (Note that it's
important to do a KillIO on all I/O before closing the serial port!) There are a couple of
reasons for closing the port when you're finished using it. First, it conserves power on the
Macintosh portable models; while the serial port is open the SCC drains the battery. Second,
closing the serial port avoids conflicts with other applications that use it. Inside Macintosh is
incorrect in stating that you shouldn't close the port after issuing an OpenDriver call.
Most network drivers shouldn't be closed when an application quits, on the other hand, since
other applications may still be accessing the driver.
Q We've tried to put old CDs to productive use. We use them for coasters, but you can only drink so many
Mountain Dews at once. We've even resorted to using them for skeet-shooting practice. Can you suggest
other good uses for my old CDs?
A It's not well known that stunning special effects in some films, such as Terminator 2, were
produced with the aid of compact disc technology. For example, the "liquid metal" effect used
for the evil terminator was nothing more than 5000 remaindered Madonna CDs, carefully
sculpted into the shape of an attacking android. And did you know that dropping a CD into a
microwave oven for five seconds or so produces an incredible "lightning storm" effect? (Kids,
don't try this at home; we're trained professionals.) For ideas of what you can do with old CDs,
see the letter on page 5.
Q I need to launch an application remotely. How do I do this? The Process Manager doesn't seem to be able
to launch an application on another machine and the Finder Suite doesn't have a Launch Apple event.
A What you need to do is use the OpenSelection Finder event. Send an OpenSelection to the
Finder that's running on the machine you want to launch the other application on, and the
Finder will resolve the OpenSelection into a launch of the application.
As you can see if you glance at the OpenSelection event in the Apple Event Registry, there's
one difficulty with using it for remote launching: You have to pass an alias to the application
you want to launch. If the machine you want to launch the application on is already mounted as
a file server, this isn't important, since you can create an alias to that application right at that
moment. Or, if you've connected in the past (using that machine as a server) you can send a
previously created alias and it will be resolved properly by the Finder on the remote machine.
However, if you want to launch a file without logging on to the other machine as a server,
you'll need to use the NewAliasMinimalFromFullPath routine in the Alias Manager. With this,
you'll pass the full pathname of the application on the machine you want to launch on, and the
Alias Manager will make an alias to it in the same way it does for unmounted volumes. The
obvious drawback here is that you'll need to know the full pathname of the application -- but
there's a price to pay for everything. The FinderOpenSel sample code on the Developer CD
Series disc illustrates this use of the NewAliasMinimalFromFullPath routine.
Q When I try to link my driver in MPW 3.2, it tells me
### Link: Error : Output must go to exactly one segment when using
"-rt" (Error 98)
### Link: Errors prevented normal completion.
In all my source files I have #pragma segment Main {C} and SEG 'Main' {Asm} directives. Why is it
doing this? What factors determine how segments are assigned (besides the #pragma stuff)? How can I
get it to work?
A The problem is probably that you're including modules from the libraries that are marked for
another segment. Usually the culprit here is that some of the routines in StdCLib or some other library are marked for the StdIO segment. You can generally fix this by using the -sg
option to merge segments, either explicitly by naming all the segments you want to merge, or
implicitly by just putting everything into one segment. You probably want to do the latter,
because you only want one segment anyway. Thus, what you should do is add the option "-sg
Main" to your link line in place of the "-sn Main=segment" option. This will merge all
segments into the Main segment, making it possible to link.
Q How do I count the number of items in a dialog without System 7's CountDITL? My solutions are either
messy or dangerous: (1) Fiddle with the dialog's item list, (2) Try to find out which DITL the dialog
used and read the count from the DITL resource, or (3) Repeatedly call GetDItem until garbage is
returned. :-(
A It's possible to use the CountDITL function with system software version 6.0.4 or later if the
Macintosh Communications Toolbox is installed, because it's included as a part of the Toolbox.
It's also possible, as you've found, to use the first two bytes of the DITL resource to get the
number of items in the item list (see Inside Macintosh Volume I, page 427). If the handle to your
DITL resource is defined as ditlHandl, for example, you can get at the number of items as
follows:
short **ditlHandl;
ditlHandl = (short **)ditlRez;
itemcount = (**ditlHandl) + 1;
Q How does Simple Player determine whether a movie is set to loop or not? Movie files that are set to loop
seem to have a string of 'LOOP' at the end of the 'moov' resource. Does Simple Player check 'LOOP'?
A Simple Player identifies whether movies are set to loop by looking within the user data atoms
for the 'LOOP' atom, as you've noticed. It's a 4-byte Boolean in which a value of 1 means
standard looping and a value of 0 means palindrome looping. Your applications should add the
user data 'LOOP' atom to the end of the movie when a user chooses to loop. We recommend
this method as a standard mechanism for determining the looping status of a movie. If the
'LOOP' atom doesn't exist, there's no looping. The calls you need to access this information
are GetMovieUserData, GetUserData, AddUserData, and RemoveUserData, as defined in the
Movie Toolbox chapter of the QuickTime documentation. For more information see the
Macintosh Technical Note "Movies 'LOOP' Atom."
Q Calling SetFractEnable seems to force the width tables to be recalculated regardless of the setting of the
low-memory global FractEnable. We're calling this routine at a central entry point for any document, as
it's a document-by-document attribute. We then unconditionally call SetFractEnable(false) on exit back
to the event loop, to be nice to other applications. Calling SetFractEnable(false) seems to trigger the
recalculation even though FractEnable is false. What's the best way to get around this?
A Your observation is correct. The SetFractEnable call stuffs the Boolean parameter (as a single
byte) into the low-memory global $BF4 and indiscriminately invalidates the cached width table
by setting the 4-byte value at $B4C (LastSpExtra, a Fixed value) to -1. Obviously, it wasn't
anticipated that SetFractEnable could be called regularly with a parameter that often doesn't
change the previous setting. (By the way, the same observation applies to SetFScaleDisable.)
In your case, you may want to keep track of the fractEnable setting in your application and
avoid redundant SetFractEnable calls. (Note that it's not a good idea to use the above insider
information and poke at $BF4 and $B4C on your own!)
You don't need to think of other applications when resetting fractEnable; it belongs to those
low-memory globals that are swapped in and out during context switches to other applications.
Q It looks as though the Event Manager routine PostHighLevelEvent could be (ab)used to send low-level
messages, like phony mouse clicks and keystrokes. Would this work?
A No; unfortunately, this won't work. A few reasons why:
- The only applications that will receive high-level events (and their descendants, like Apple
events) are applications that have their HLE bit set in their SIZE resource. If you try to
send (or post) an HLE to an older application you'll get an error from the PPC Toolbox
telling you that there's no port available.
- There's no system-level translator to convert these things. There are currently translators to
change some Apple events. Specifically, the Finder will translate any "puppet string" event
into puppet strings for non-System 7 applications (odoc, pdoc, and quit), but these are very special.
- The only way to send user-level events such as mouse clicks through HLEs is to use the
Apple events in the MiscStndSuite shown in the Apple Event Registry. And all those events assume that the receiving application will do the actual translations to user actions
themselves.
- HLEs come in through the event loop. So even if it were possible (through some very nasty
patching to WaitNextEvent) to force an HLE into a non-HLE-aware application, the event
would come in with an event code of 23 (kHighLevel) and the targeted application would
just throw it away.
So the answer is that you can't send user-level events to an HLE-aware application. If you want
to drive the interface of an old application in System 7, you have to use the same hacky method
you used under all previous systems. This, by the way, is one of the main reasons why
MacroMaker wasn't revised for System 7. Apple decided that it wasn't supportable and that we
would wait for applications to update to System 7 and take advantage of third-party Apple event
scripting systems.
Q What's the recommended method for allowing an AppleTalk node to send packets to itself using
AppleTalk's self-send mode (intranode delivery), assuming customers are running various versions of
AppleTalk? There used to be a control panel called SetSelfSend that would turn on AppleTalk self-send
mode at startup time. Should we use that control panel or should we use the PSetSelfSend function in
our program to set the self-send flag ourselves?
A AppleTalk self-send mode requires AppleTalk version 48 or greater. You can check the
AppleTalk version with Gestalt or SysEnvirons. All Macintosh models except for the Macintosh
XL, 128, 512, and Plus have AppleTalk version 48 or greater in ROM.
The SetSelfSend control panel is still available on the Developer CD Series disc (Tools &
Apps:Intriguing Inits/cdevs/DAs:Pete's hacks-Moof!:SetSelfSend). However, we don't
recommend it as a solution if you need to use self-send mode in your program. Instead, you
should use the PSetSelfSend function to turn self-send mode on with your program.
AppleTalk's self-send mode presents a problem. Any changes made to the state of self-send will
affect all other programs that use AppleTalk. That is, self-send mode is global to the system.
Because of this, programs using self-send should follow these guidelines:
- If you need self-send for only a brief period of time (for example, to perform a
PLookupName on your own node), you should turn it on with PSetSelfSend (saving the
current setting returned in oldSelfFlag), make the call(s) that require self-send, and restore
self-send to its previous state.
- If you need self-send for an extended period of time (for example, the life of your
application) in which your program will give up time to other programs, you should turn
self-send on and leave it on -- do not restore it to its previous state! Since other programs
running on your system (that aren't well-behaved) may turn off self-send at any time,
programs that require self-send should periodically check to make sure it's still on with either PSetSelfSend or PGetAppleTalkInfo. Apple's system software has no compatibility
problems with self-send -- that is, it doesn't care if it's on or off -- so leaving it on won't
hurt anything.
Q In a version 2 picture, the picFrame is the rectangular bounding box of the picture, at 72 dpi. I would
like to determine the bounding rectangle at the stored resolution or the resolution itself. Is there a way to
do this without reading the raw data of the PICT resource itself?
A With regular version 2 PICTs (or any pictures), figuring out the real resolution of the PICT is
pretty tough. Applications use different techniques to save the information. But if you make a
picture with OpenCPicture, the resolution information is stored in the headerOp data, and you
can get at this by searching for the headerOp opcode in the picture data (it's always the second
opcode in the picture data, but you still have to search for it in case there are any zero opcodes
before it). Or you can use the Picture Utilities Package to extract this information.
With older picture formats, the resolution and original bounds information is sometimes not as
obvious or easily derived. In fact, in some applications, the PICT's resolution and original
bounds aren't stored in the header, but rather in the pixel map structure(s) contained within the
PICT.
To examine these pixMaps, you'll first need to install your own bitsProc, and then manually
check the bounds, hRes, and vRes fields of any pixMap being passed. In most cases the hRes
and vRes fields will be set to the Fixed value 0x00480000 (72 dpi); however, some applications
will set these fields to the PICT's actual resolution, as shown in the code below.
Rect gPictBounds;
Fixed gPictHRes, gPictVRes;
pascal void ColorBitsProc (srcBits, srcRect, dstRect, mode, maskRgn)
BitMap *srcBits;
Rect *srcRect, *dstRect;
short mode;
RgnHandle maskRgn;
{
PixMapPtr pm;
pm = (PixMapPtr)srcBits;
gPictBounds = (*pm).bounds;
gPictHRes = (*pm).hRes; /* Fixed value */
gPictVRes = (*pm).vRes; /* Fixed value */
}
void FindPictInfo(picture)
PicHandle picture;
{
CQDProcs bottlenecks;
SetStdCProcs (&bottlenecks);
bottlenecks.bitsProc = (Ptr)ColorBitsProc;
(*(qd.thePort)).grafProcs = (QDProcs *)&bottlenecks;
DrawPicture (picture, &((**picture).picFrame));
(*(qd.thePort)).grafProcs = 0L;
}
Q The code I added to my application's MDEF to plot a small icon in color works except when I hold the
cursor over an item with color. The color of the small icon is wrong because it's just doing an InvertRect.
When I drag over the Apple menu, the menu inverts behind the icon but the icon is untouched. Is this
done by brute force, redrawing the small icon after every InvertRect?
A The Macintosh system draws color icons, such as the Apple icon in the menu bar, every time
the title has to be inverted. First InvertRect is called to invert the menu title, and then
PlotIconID is called to draw the icon in its place. The advantage of using PlotIconID is that
you don't have to worry about the depth and size of the icon being used. The system picks the
best match from the family whose ID is being passed, taking into consideration the target
rectangle and the depth of the device(s) that will contain the icon's image.
The Icon Utilities call PlotIconID is documented in the Macintosh Technical Note "Drawing
Icons the System 7 Way" (formerly #306); see this Note for details on using the Icon Utilities
calls.
Q The cursor flashes when the user types in TextEdit fields in my Macintosh application. This is done in
TEKey. I notice that most programs hide the cursor once a key is pressed. I don't care for this because
then I have to move the mouse to see where I am. Is this a typical fix for this problem and an accepted
practice?
A There's very little you can do to avoid this. The problem is that every time you draw anything
to the screen, if the cursor's position intersects the rectangle of the drawing being done,
QuickDraw hides the cursor while it does the drawing, and then shows it again to keep it from
affecting the image being drawn beneath it. Every time you enter a character in TextEdit, the
nearby characters are redrawn. Usually this is invisible because the characters just line up on top
of their old images, but if the cursor is nearby and visible, it will flicker while it's hidden to
draw the text. This is why virtually all programs call ObscureCursor when the user types. Also,
most users don't want the image of the cursor obscuring text they might be referring to, yet
they don't want to have to move it away and then move it back to make selections. Because it's
so commonplace, hiding the cursor probably won't bother your users; in fact, they might very
well prefer the cursor hidden. This, combined with the fact that there's very little you can do to
help the flickering, suggests that you should obscure the cursor while the user types.
Q We're using Apple events with the PPC Toolbox. We call StartSecureSession after PPCBrowser to
authenticate the user's identity. The user identity dialog box is displayed and everything looks good.
However, in the first AESend call we make, the user identity dialog is displayed again. (It isn't displayed
after that.) Why is this dialog being displayed from AESend when I've already authenticated the user
identity with StartSecureSession?
A First, a few PPC facts:
* When a PPC session is started, StartSecureSession lets the user authenticate the session (if
the session is with a program on another Macintosh) and returns a user reference number
for that connection in the userRefNum field of the PPCStartPBRec. That user reference
number can be used to start another connection (using PPCStart instead of
StartSecureSession) with the same remote Macintosh, bypassing the authentication dialogs.
* User reference numbers are valid until either they're deleted with the DeleteUserIdentity
function or one of the Macintosh systems is restarted.
* If the name and password combination used to start a session is the same as that of the
owner of the Macintosh being used, the user reference number returned refers to the default
user. The default user reference number normally is never deleted and is valid for
connections to the other Macintosh until it's deleted with DeleteUserIdentity or one of the
Macintosh systems is restarted.
With that out of the way, here's how user reference numbers are used when sending high-level
events and Apple events: When you first send a high-level event or an Apple event to another
Macintosh, the code that starts the session with the other system doesn't attempt to use the
default user reference number or any other user reference number to start the session, and it
doesn't keep the user reference number returned to it by StartSecureSession. The session is
kept open for the life of the application, or until the other side of the session or a network
failure breaks the connection. When you started your PPC session, StartSecureSession created a user reference number that
could be used to start another PPC session without authentication. However, the Event
Manager knows nothing of that user reference number, so when you send your first Apple
event, the Event Manager calls StartSecureSession again to authenticate the new session. Since
there isn't any way for you to pass the user reference number from the PPC session to the
Event Manager to start its session, there's nothing you can do about this behavior.
Q How can I make my ImageWriter go faster?
A To make your ImageWriter go blazingly fast, securely tie one end of a 12-foot nylon cord
around the printer and the other end around your car's rear axle. If your car has a manual
transmission, hold the clutch in and race your car's engine until the tachometer is well into the
red zone. Slip the clutch and off you go! If your car has an automatic transmission, you can
approach the same results by leaving plenty of slack in the rope before peeling out.
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 Chris Berarducci, Tim Dierks, Steve Falkenburg, Marcie "M.
G." Griffin, Charles Grosjean, Bill Guschwan, C. K. Haun, Dave Hersey, Dennis Hescox, Rich Kubota, Scott Kuechle,
Edgar Lee, Jim Luther, Joseph Maurer, Kevin Mellander, Guillermo Ortiz, Dave Radcliffe, Greg Robbins, Kent Sandvik, Eric
Soldan, Brigham Stevens, Dan Strnad, Forrest Tanaka, and John Wang for the material in this Q & A column. *
Have more questions? Need more answers? Take a look at the Q & A Technical Notes on the Developer CD Series disc
and the Dev Tech Answers library on AppleLink.*
