Macintosh Q & A

Macintosh Developer Technical Support

Q I'm having trouble figuring out how to convert some assembly trap patches for selector-based traps into PowerPC native code. Do you have any suggestions for a clean way of doing this, ideally so that it works on both 680x0-based machines and the Power Macintosh? 

A Currently there's no way to patch a selector-based trap with a native or fat patch. (A list of selector-based traps can be found in the back of Inside Macintosh X-Ref .) The problem arises from the fact that each routine associated with a single dispatch-based trap can have a different parameter list (that is, a different number of parameters and different sizes for each parameter). Basically there's no way for mixed mode to handle the variable stack frame sizes associated with selector-based traps. This is the same thing that makes head/tail patching them so much of a pain in C.

We're in the process of trying to determine whether developers have a pressing need to patch selector-based traps with native code. For now, keep all such patches in 680x0 code. If a patch to a particular routine is itself very time-intensive (which is rarely the case), the 680x0 patch can call through to a native implementation.

Q I'm writing a QuickDraw GX print driver for a plotter and need to send initialization and termination strings to the plotter. How can I determine from my driver if I'm printing the very first or last page, regardless of the number of copies? I'd like to have this information in GXStartSendPage and GXFinishSendPage, respectively, so that I can send my strings then. 

A We recommend that you do any pre-first-page setup in GXOpenConnection (after forwarding) and any post-last-page teardown in GXCloseConnection (before forwarding). (Although the documentation is a bit ambiguous on this point, you can  send information with GXBufferData and GXWriteData from GXCloseConnection, before forwarding.) If there's some reason that this won't work for you, and you really need the information in GXStartSendPage and GXFinishSendPage, you'll have to use global data.

In some override before GXStartSendPage (perhaps GXImageDocument), initialize a global page counter to 0. In your GXStartSendPage override, check this flag, and then bump it after forwarding. If your check finds that the flag is 0, no pages of the document have been sent yet.

To determine when the last page has printed, you'll also need to use global data. Somewhere (again, GXImageDocument is fine) call GXCountPages, get the number of copies from the job's 'copy' collection item, and multiply. In your GXFinishSendPage override, compare the value you bumped in GXStartSendPage to this multiplied value. When they're equal, you're just finishing the last page.

Q How do client and server desktop printers (shared printers) synchronize in QuickDraw GX? Specifically, what we're trying to find out is (for a server desktop printer on one machine, and a matching client on another):

• If a user on the client machine sets a papertype in an input tray, is it reflected on the server in the Input Trays dialog? If not, what's the correct behavior for the client and the server machines (for example, should the client Input Trays dialog be read-only)?
• Generally, what resources and data are transmitted between the host and the client, and when? Is there a mechanism for controlling which resources will be sent or kept local (preferably on a resource-by-resource basis)?

A Resources are transmitted to desktop printers in only one direction -- server to clients. Also, only resources with IDs greater than 0 are moved to the clients. Therefore, it's appropriate to make the Input Trays dialog on clients read-only. Even though Apple's drivers don't do this, it's the more correct approach. You can find out whether you're on a server or a client by checking the desktop printer's 'comm' resource; if its type identifier is 'ptsr', you're on the client; otherwise, you're on the server.

If you need to have data sent from the client to the server, you should fetch the resources at GXImageJob time (before forwarding) and then roll them into a job collection item. In the appropriate communication message, look for the collection item and use that data. Since GXImageJob is always called (shared printers or not), and it's called on the client if you're working with shared printers, this method should always work.

Q If I want to add additional properties to the paper stock (such as paper color), and I call AddCollectionItem(GXGetPaperTypeCollection(paper), . . . ), will that new collection be stored in the desktop printer's configuration file, or is that something I must manage? I seem to be losing my collection between invocations of the Trays dialog. 

A The papertype collection items you add won't be flattened to disk and stored in the desktop printer via your Trays dialog. There's no way to make collection item changes and have them saved with the disk-based papertype, wherever it may be stored. You need to manually save the information in your desktop printer (or some other place) as resources, and then match that up with the papertypes when you want to use them. You should match up the papertypes and the resources based on the names of the papertypes.

You can still take advantage of the papertype collection to hold your paper color information, as long as you also have the information stored on disk. The papertype collection will be around as long as the papertype's job is around. For example, if you load the color info from the desktop printer and put it in a papertype collection item at despoolpage time, it stays there throughout the entire print cycle, and wherever the job goes, it goes.

Q I'm having a problem resizing text elements in our QuickTime application. I'm trying to modify the element's size by calling SetTrackDimensions, and it seems to do what I want for all element types except text. For text tracks, the element's bounding box is resized correctly, but the text characters are scrunched into the upper left corner of that rectangle, still at their original size. In other words, SetTrackDimensions seems to scale the track bounds, but not the text characters themselves. Any idea what's going on? 

A This is a bug. As you determined, SetTrackDimensions is only changing the size of the track box, not setting the correct scaling factor or internal flags. To work around this problem, use GetTrackMatrix to retrieve the current matrix, then ScaleMatrix to change it, and finally SetTrackMatrix to make it take effect.

Q Do you know why "OCE Mail Enclosures" appears as a volume when I index through all volumes using PBHGetVInfo? Is there any way to filter out this "volume"? 

A The reason "OCE Mail Enclosures" shows up is that it's the volume for an external file system (XFS) that AOCE installs in order to support access of letter enclosures via FSSpecs from the mailer and other parts of the AOCE system. This enables the direct access that the mailer provides in the enclosure fields of letters, allowing users to manipulate enclosures like any other file in the Finder, copying and even launching them directly from the enclosure pane.

To filter out the "OCE Mail Enclosures" volume, you should check the Finder flags of the root directory in each volume to determine whether that volume should be visible to the user. The Finder flags for directories are located in the ioDrUsrWds field in the dirInfo variant of the CInfoPBRec structure. If the fInvisible bit is set, you should not display that volume to the user. Here's a snippet:

void main(void)
{
    HVolumeParampBlock; CInfoPBRec cBlock;
    Str255 volName, fName;
    OSErr err;

    pBlock.ioNamePtr = volName;
    err = noErr;
    for (pBlock.ioVolIndex=1; err==noErr; pBlock.ioVolIndex++) {
        err = PBHGetVInfo((HParmBlkPtr)&pBlock, false);
        if (err==noErr) {
            cBlock.dirInfo.ioNamePtr = fName;
            cBlock.dirInfo.ioVRefNum = pBlock.ioVRefNum;
            // Query the directory info ioDrDirID.
            cBlock.dirInfo.ioFDirIndex = -1;
            // This is the root directory.
            cBlock.dirInfo.ioDrDirID = 2; 
            err = PBGetCatInfo(&cBlock, false);
            if (err==noErr) {
                if ((cBlock.dirInfo.ioDrUsrWds.frFlags & 
                fInvisible)!=0)
                // It's invisible.
                . . .
            }
        }
    }
}

Q I have a dialog with two editText fields. When I populate the two fields with text, whichever field I populate first is displayed two pixels too high within its item. The second field is fine, and it has the "focus" of the dialog. When I click in the first field, any new text is added at the correct height, but unfortunately that's two pixels below where the previous text was drawn. The fields are both 10-point plain Geneva, and the editText boxes are 16 pixels high. Any ideas? 

A The Dialog Manager has a bug that causes problems when you use an alternate font or size for the editText items. The problem is how it draws the text initially in the dialog: the text for the currently active item is drawn by manipulating the dialog's TextEdit record, and the text for all other items is drawn by calling TextBox. The solution is to call SelIText just before you call SetIText each time you populate a field with text.

Q How can I convert an RGB color into an index to a palette created by my application? Color2Index converts the RGB color to an index to the current device's color table, but that's not what I want. 

A There's no single call that will give you a palette match to an RGB color. You'll have to do this: call Color2Index to get the closest match to your RGB request; call Index2Color to get the device's indexed color from your match; search the palette yourself to find the color match (according to RGB value); and call Color2Index to verify that you have the color you're looking for.

Alternatively, you can create an off-screen GWorld, call Palette2CTab to convert your palette to a color table, and call UpdateGWorld to insert your new color table in your off-screen GWorld. Then, to find the index of an RGB color, make your GWorld the active device and call Color2Index.

Q I've tried in vain to find a way to print white text on a black background. Is there a way to do this, and if so, how? 

A The trick is to use the srcBic pen mode:

FillRect(theRect, black);
PenMode(srcBic);
DrawString(myString);

Q In our application, the user can select an area of an image and drag it around. I want to show this visually by inverting the region under the current mouse coordinate as the user moves the mouse around. Inverting the region is nice because I can invert it again to get the unselected pixels back. It's not nice, however, in that a 50% gray color looks the same when it's inverted. To fix this problem, I tried using PaintRgn with an RGBForeColor of r,g,b = 0x8000 and a transfer mode of addOver. This works great on 24-bit screens, but it seems that on 256-color screens, applying this operation twice doesn't quite return to the original color. Am I going to have to use a custom color search procedure? 

A You get the results you want on direct devices but not on indexed ones, and unless you're extremely lucky with your color table, this is how it will always work. The problem is that the mode calculations are done with the actual RGB values used (the ones available in the color table), not the ones you request. On indexed devices there's almost always a difference between the two, so unless your color table happens to have the exact color you request, there will be "errors." This never happens on direct devices because all colors are available -- the operations work on direct RGB values and are never mapped through color tables.

The solution is either to set up your color tables or palettes to make sure you get the results you want each time, or to install a custom color search procedure if that's what you'd prefer.

Q After we call CMOpen and a connection is established, a dialog is displayed and eventually goes away. Unfortunately, the C++ object framework we use is bombing because it's getting a deactivate event for that window, which belongs to the Communications Toolbox. We wrote a kludge that sets a flag after the call to CMOpen is finished and eats the deactivate event if the flag is set. Is there a better way for us to tell whether to let the class library handle the event or to handle it ourselves? 

A A window or dialog created by a connection tool has the connection record handle stored in the refCon field. The sequence, then, is to check the event record to find out if the event is tied to operations in a window and, if so, check the window's refCon against your connection handles. If there's a match, call CMEvent for that event; otherwise pass it on to the framework. You'll probably need to write a handler for your class library to do this properly, overriding the default window-handling routines for this special case.

Q When our application opens a Communications Toolbox tool, we issue a CMOpen with the asynchronous flag true and go into a loop, calling CMIdle and then CMStatus until we see the cmStatusOpening flag go down or the cmStatusOpen flag come up. When we use the Express Modem Tool (on a Macintosh Duo 230), those flags never change. Should we be doing something different or is there a problem with that tool? 

A The Express Modem Tool uses a background process (coupled tightly with the hardware implementation) to actually move data. Unless your application yields processor time through the WaitNextEvent cycle, the background process is stuck when you call the tool asynchronously. (The synchronous call has been massaged to give the process time, of course.)

What you're doing, essentially, is making the asynchronous call synchronous by trapping your application in this kind of loop. The proper thing to do would be either to use the call synchronously or to continue to use it asynchronously but exit back to the main event loop and look for the flags from there. When the appropriate flag is set, you can then dispatch off to a handler routine. Even better, use a completion routine to notify the application that the CMOpen has completed and obtain the function result from the ConnHandle errors field.

Q I've implemented a variant of the CMChoose dialog based on the Choose.p sample code in Inside the Macintosh Communications Toolbox, page 323. The problem I have is that all the fields of the dialog appear in 12-point Chicago rather than the 9-point Geneva that tool dialogs usually use, so the dialog looks really tacky. How can I fix this? 

A The critical thing is knowing when and where to set the window's text characteristics. Tools provide a resource ('finf' or 'flst', defined in SysTypes.r and CTBTypes.r) that gives you the font information for the tool's DITL. Between the CMSetupPreflight and CMSetupSetup calls, you should fetch the font, size, face, and mode from the resource and set your custom dialog's port to match it. You also need to stuff the same information into the dialog's TextEdit record so that the editable fields show up correctly. Controls provided in a DITL by Communications Toolbox tools have the useWFont bit set so that they always follow the settings in the dialog's port.

Q We're calling CMListen synchronously in our application, and if it times out an error alert is displayed that doesn't go away until the user clicks OK (or after a very long time). Is it possible not to have this dialog displayed, or to have it go away quickly as the "connected" dialog does? 

A With regard to all Communications Toolbox interface components, you can only leave them all on or turn them all off with the flag parameter to CMNew (cmQuiet and cmNoMenus). We don't know of any way to affect the behavior of specific elements like the error dialog raised by CMListen. (CMListen is best implemented in an application as an asynchronous call, particularly in the cmQuiet mode.)

Q The Connection Manager sample code in Inside the Macintosh Communications Toolbox sets the buffer sizes for cmDataIn and cmDataOut to 1K and the rest to 0, and there's a comment that the other channels are to be ignored. Then, in the description of CMNew, it says, "To have the tool set the size of these buffers, your application should put zeros in the array." What's the recommended way to go? 

A You should consider the buffer sizes you set in the CMBufferSizes array as a request for buffers. The tool's implementation will always override your choices based on what the developer felt was the proper thing to do. Many programmers initialize the array to all zeros and let the tool defaults be set; there's some argument for increasing the sizes on network protocols for efficiency, but it's up to the tool designer to determine what makes the best sense. Rather than depend on any particular buffer sizes in your application, you should deal with what the tool allocates dynamically.

Q What is that green slime that you can buy in toy stores made of? 

A We're not exactly sure what the composition of that stuff is, and the toy companies aren't about to tell us, but we're pretty sure that it's some sort of polymer that's cross-linked via hydrogen bonding. Hydrogen bonds are relatively weak, and can be easily pulled apart. That's why these materials behave like "slow liquids" and eventually seek their own level.

A very satisfying white version of slime can be concocted at home from common ingredients as follows: Mix 1/2 cup water and 1/2 cup white glue in a bowl. In another bowl (or a cup) dissolve 1 teaspoon borax in 1/2 cup water (make sure the borax is completely dissolved; it may take a minute of stirring). Pour the borax solution into the glue solution, stirring rapidly and constantly. Keep stirring for a minute; then reach in with your fingers and keep mixing, trying to break up the lumps. At first the material will be lumpy and wet, but soon it will become smooth and rubbery. This recipe makes a blob the size of a grapefruit. Use less water with the glue for stiffer slime. Store in an airtight container, and keep it away from carpets!

Q Nothing in the documentation for MacTCP deals with the state of register A5 if an ioCompletion routine is specified within struct CntrlParam (MacTCP version 1.1 documentation, page 7). I've been manually preserving and setting A5 with some inline assembly code but wonder if this is really necessary. If I must set A5, and want to use the same source code in the 680x0 and PowerPC environments, how do I go about it? 

A When MacTCP calls the application's ioCompletion routine, it restores the application's A5 register, so the application shouldn't worry about this (the MacTCP driver takes care of it). On a Power Macintosh, you can still set register A5 in the emulator as you did before (with SetA5 and SetCurrentA5). However, be aware that with native code, register A5 is no longer used to store references to global variables. Any piece of PowerPC native code, even standalone code, can have its own global variables without making its own A5 world.

Q When a driver is operating synchronously, what kinds of system calls are prohibited? Specifically, can I make memory allocation calls and file system calls from the driver? 

A If your driver is called synchronously, you should be able to allocate memory and make file system calls and other system calls that move memory. If it's called asynchronously, you should not  make these calls. There's one important exception to this guideline: the Macintosh file system isn't reentrant, so in a disk driver or a network driver that serves the file system, you must not make any calls to the file system, as you will tie it into metaphorical knots.

Q I'm creating an application from an existing file by adding CODE resources to it, setting the bundle bit, clearing the inited bit, closing the file, and flushing the volume. My problem is that the Finder doesn't recognize the change immediately. I have to move the file to another folder before the icon changes and it's recognized as an application. What do I need to do to have the Finder recognize the change immediately? 

A The problem you're having stems from the fact that the Finder only scans for changes about every 10 seconds. To make the Finder aware of changes before that, you need to change the modification date of the parent directory. Use a routine like this:

OSErr TouchDir(short vRefNum, long dirID)
{
    CInfoPBRec info;
    Str255 name;
    OSErr theErr;
    
    info.dirInfo.ioDrDirID = dirID;
    info.dirInfo.ioVRefNum = vRefNum;
    info.dirInfo.ioNamePtr = name;
    info.dirInfo.ioFDirIndex = -1;
    theErr = PBGetCatInfo(&info, false);
    if (!theErr) {
        info.dirInfo.ioCompletion = 0;
        info.dirInfo.ioDrDirID = info.dirInfo.ioDrParID;
        info.dirInfo.ioFDirIndex = 0;
        GetDateTime(&info.dirInfo.ioDrMdDat);
        theErr = PBSetCatInfo(&info, false);
    }
    return theErr;
}

The Finder will rescan the specified directory immediately after this routine updates the modification date, usually well within one second.

Q Does the idleProc of AESend get called before every event is sent, even those to the current process (which are directly dispatched)? What I really care about is whether WaitNextEvent is called each time. 

A AESend's idleProc will be called if kAEWaitReply is the sendMode. In this mode the Apple Event Manager uses the Event Manager to send the event. The Event Manager then calls WaitNextEvent on behalf of your application. This causes your application to yield the processor, giving the server application a chance to receive and handle the Apple event. You must supply an idleProc in order to process any update events, null events, operating system events, or activate events that occur while your application is waiting for a reply.

If you use kAENoReply or kAEQueueReply as the sendMode, AESend will immediately return after using the Event Manager to send the event. Your idleProc will never be called (in the case of kAEQueueReply, it's assumed that you want to receive your reply via your application's event queue, and you must install a handler for the reply Apple event).

Likewise, your idleProc will never be called in the case of a direct dispatch. In doing a direct dispatch you're sending an Apple event to yourself using the typeProcessSerialNumber and kCurrentProcess. These events are delivered directly, bypassing the event queue and executing your handler routine directly. For more information, see the Macintosh Technical Note "SendToSelf: Getting in Touch With Yourself Via the Apple Event Manager" (Interapplication Communication 1).

Q I'm having a problem sending custom Apple events over the network. We have a background-only application on one machine sending custom Apple events to another machine via LocalTalk. If we manually pull the LocalTalk cable out from the back of the sending Macintosh, the event is never received on the remote machine, but an error is never returned by AESend. AETracker logs show that the event is being sent with no error, but AETracker on the remote machine shows no sign of the event. We've also seen a similar thing happen when phone lines are bad. Note that in both cases, other events are sent between the machines just fine. What gives? 

A The reason AESend doesn't report an error in cases like the one you mention is because it can't. As soon as the event is sent, AESend returns noErr indicating that the event has been handed off to the PPC Toolbox for sending. You're then back in your main event loop and doing other things. If for some reason the connection goes down (or there's any other transmission problem), there may be a resulting error from the network layer that's actually transporting the event, but the resulting error may not occur for seconds or even minutes. At that point there's no way for the AESend that sent the event to detect the error.

We saw a good example of this recently using a standard Ethernet connection between two machines. The network connection was broken between the machines and an event was sent from one to the other. AESend returned noErr on the sending Macintosh, and as long as we reconnected the two machines before the end of the associated timeout period -- two minutes -- the event was received. If we waited longer the event never made it. But in either case AESend returned noErr.

There are a couple of ways to address the problem. The first way is to use kAEWaitReply when sending your event; however, you give up the processor in favor of ensuring a reply. The other solution is to pass kAEWantReceipt in the sendMode parameter of AESend and have a timeout for the amount of time you're willing to wait for a reply.

Q We have two questions regarding AppleScript. First, what's the significance of Begin Transaction and End Transaction for a single-threaded application? Do we need to support these two events if we don't send events or scripts to another application? The Apple Event Registry says to return a transaction ID for the Begin Transaction call and to check for the transaction ID of all the incoming Apple events. Is this really necessary? Second, what's the user interface guideline for the Print Document ('pdoc') event in the required suite? Currently, I bring the application to the front by calling AEInteractWithUser (only if both the server and the client are in the same machine) and open the print job dialog box. 

A A single-threaded application doesn't need to support Begin or End Transaction. If you need transactions, you may implement them as you see fit. Regarding the 'pdoc' event, what you're doing is correct. When you receive a 'pdoc' event, you should call AEInteractWithUser and check the result: if you get noErr (meaning you can interact), open the standard print job dialog; if you get errAENoUserInteraction (you can't interact), just do whatever the default is for that document, printing without interaction.

Q I'm doing a project where I need about 1500K for my own off-screen GWorlds and sundry data structures, and we're targeting the 4 MB Macintosh LC. Here's the kicker: we need Text to Speech. I'd like to know more precisely how the memory allocation works in the Speech Manager so that I know what our options are -- for example, how much memory gets allocated from the system versus how much from my application heap. 

A When trying to preflight the memory needs for an application that uses Text to Speech, keep in mind that there are at least three different managers involved in the production of speech on the Macintosh: the Component Manager, the Speech Manager, and the Sound Manager. All these have their own memory allocation schemes and take memory from different places.

As a rough rule of thumb, to use Text to Speech in a robust manner, plan on adding 250K for each SpeechChannel you expect to keep open at any given time; this should accommodate both MacinTalk 2 and MacinTalk Pro voices. If this causes a minimum application size that's not acceptable, you can add only 50K for each MacinTalk 2 channel you allow to be open at a time and include in your documentation instructions on how to increase the size if the user decides to use MacinTalk Pro voices instead.

The more complete scenario goes like this: The Component Manager takes up about 20K of the system heap (possibly slightly less when no components are open). The Speech Manager code and data use around 20K of system heap, and should be a one-time investment (note that little variance should be expected from version to version). The Sound Manager memory usage depends on the version and other factors, but a good estimate is 30K per SndChannel. Note that the Sound Manager code goes into the system heap, with sound buffers and sound data being allocated in the application heap.

The amount of space needed for the Text to Speech engine code and data (such as pronunciation dictionaries and rules data) varies quite a bit between MacinTalk 2 (about 100K) and MacinTalk Pro (about 300K); this memory is allocated in the system heap whenever possible to make it available to different applications using the same engine. If the Speech Manager can't allocate the necessary space in the system heap, it tries to get it from the application heap. Naturally when this happens the code and data cannot be shared across applications. There's also some Text to Speech engine-specific SpeechChannel data whose size varies from engine to engine: MacinTalk 2 uses roughly 10K and MacinTalk Pro uses about 175K. Finally, there's the voice data and code: MacinTalk 2 takes between 20K to 40K depending on the chosen voice, while MacinTalk Pro voices can use between 300K and 2.25 MB of RAM. Again, the memory needed for voice data and code is allocated from the system heap if possible to allow sharing between applications using the same voices; if there's no room in the system heap, the Speech Manager tries to load this in the application heap, and no sharing is possible.

Finally (you knew this was coming, didn't you?), be aware that these numbers may change in the future. Use them as a guide, but as always, don't depend on them.

Q What should we do when renaming a document that contains a publisher section? I try to call AssociateSection with the already registered section and the new FSSpecPtr. AssociateSection returns no error and I unregister the publisher section. But the next time I open up and register the publisher section of that document, I get a -463 error code on RegisterSection. What am I doing wrong? 

A AssociateSection doesn't change any information in the edition container file, which is where this needs to be changed; it only acts on the "hot" links the Edition Manager is currently maintaining with any open documents that are using a section. What you have to do if you rename a publishing document is to open the publisher and update it. When you call OpenNewEdition with the new file name, that will update things. This means that a "save as" must dirty all your publisher sections, which slows you down a bit and may be counterintuitive. But the only other option would be to update the alias directly, and that would be bad.

Q I'm working on a video-conferencing solution that uses the video digitizer (vdig) incorporated in the Macintosh Quadra 840AV. I want to capture data from the system's built-in video hardware using the VDCompressOneFrame and VDCompressDone calls. I have the following questions about the vdig that supports the 840AV built-in video hardware:

• What's the header and data format for the captured video?
• What's the compressor type (cType) for this compression format?
• Does this compressor support more than one spatial compression setting and, if so, what are the data formats for the compression settings? 

A We can't provide information regarding the data format of the captured video. It's considered proprietary and confidential, except in cases where the codec in use is an industry standard like JPEG. Fortunately, you don't need to know the data format if you're using the correct QuickTime vdig and Image Compression Manager calls to manipulate the data.

We don't think you should use the vdig directly, but if you do, you can call VDGetCompressionType to determine the compression types it supports. You can select the compression type you want to use by calling VDSetCompression. Since the vdig uses standard codecs for compression, you don't need to know the data format; all you have to do is use the codec to decompress the image data when you want to draw it. Call VDGetImageDescription to get an image description handle, which you can pass to DecompressImage along with a pointer to the data, and the Image Compression Manager will take care of decompressing the data as long as the correct codec is available.

We don't recommend using vdigs directly because every one is different and supports different features. They can be pretty hard to work with because your code will require a lot of error handling and workarounds. The sequence grabber was written to provide a seamless interface between any vdig and applications, so you can use the sequence grabber as the engine for your video-conferencing system. It was designed with this kind of flexibility in mind. For more information about the sequence grabber, see Chapter 6, "Sequence Grabber Channel Components," in Inside Macintosh: QuickTime Components .

Using the sequence grabber with the right flags, you can get high-performance grabs, even over the network. You do this by supplying application-defined functions to the sequence grabber component. If you replace the grab function on the receiver side, you can use the sequence grabber to grab right off the network on that end. On the sender side, you can replace the data function so that you'll be able to write the frames out over the network, using whatever network protocol you like.

These answers are supplied by Apple's Developer Support Center. Special thanks to Brian Bechtel, Matt Deatherage, Godfrey DiGiorgi, Steve Falkenburg, Dave Hersey, Dave Johnson, Scott Kuechle, Joseph Maurer, Kevin Mellander, Jim Mensch, Martin Minow, Guillermo Ortiz, and Brigham Stevens for the material in this Q & A column. If you need more answers, take a look at the Macintosh Q & A Technical Notes on this issue's CD. *