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:

1. I mount two server volumes from my AFP server: VolA and VolB.
2. I use the Finder to create an alias file for each volume.
3. I unmount VolA.
4. 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:

1. Allocate contiguous space immediately after the current physical end of file.
2. Allocate contiguous space separated from the current physical EOF.
3. Fail here if allocating contiguously.
4. Allocate fragmented space, where the first fragment follows the physical EOF.
5. 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.*