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):
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:
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. *