Q I noticed in QuickTime 2.5 that there are new selectors in the Movie Import API
that aren't described in Inside Macintosh: QuickTime Components. Although I found
some information in Technote QT 04, "QuickTime 1.6.1 Features," I haven't been able
to locate any information about the kMovieImportGetFileTypeSelect and
kMovieImportDataRefSelect selectors. Can you tell me something about these?
A The kMovieImportGetFileTypeSelect and kMovieImportDataRefSelect selectors
were added to support some features that were under investigation with the QuickTime
for Netscape plug-in. While these selectors are supported by some of the Apple movie
data import components, they don't provide any new functionality and there's no reason
to consider implementing them in your movie data import component at this time.
Q My application plays four QuickTime movies simultaneously from a Director
project. Each of the movies has a single music track with no other video or sound
tracks, and two of the movies use more than one instrument. The Director project
allows the user to control the volume level of each movie independently. The
application works great on the Macintosh with QuickTime 2.1, but under Windows
with QuickTime 2.1.2 only one music track plays at a time. Is it possible to hear all
four music tracks at once under QuickTime for Windows 2.1.2?
A You can do live mixing of your four QuickTime movies only if your Windows
system has four MIDI output devices. Most systems have only one. All Windows
applications suffer from this limitation unless they're clever enough to mix the tracks
on the fly, but none seem to do this.
For now, you must pre-mix the four music tracks from the four movies into one
music track in one movie. You won't be able to do live mixing unless you write your
own MIDI sequencer.
Q Can I play a compressed WAVE file on the Macintosh?
A Yes. You can use the Sound Manager to play a compressed WAVE file on the
Macintosh, but how easy it will be can vary greatly, depending on the type of
compression.
If the WAVE file is compressed using ulaw, your program will have to use either
SndPlayDoubleBuffer or SndDoCommand with bufferCmds to play the sound
(QuickTime cannot currently be used). This means that you'll have to parse the WAVE
header yourself and interact with the Sound Manager at a lower level than is possible
by simply calling SndStartFilePlay.
Currently, you can't play an IMA-ADPCM compressed WAVE file as easily as a 'ulaw'
compressed WAVE file, because the data stream of a sound compressed with Windows'
IMA-ADPCM compressor differs from the data stream of the same sound compressed
with the Macintosh's IMA compressor. To play an IMA-ADPCM compressed WAVE file
on the Macintosh, your application will first have to decompress chunks of the sound
into memory, then have the Sound Manager play those chunks. You can do this either by
calling SndPlayDoubleBuffer or by using bufferCmds. Of course, if the uncompressed
sound fits completely into memory, you can simply use SndPlay on that one
uncompressed buffer.
To play a WAVE file that uses a custom compression algorithm, you can either write
your own 'sdec' (sound decompressor) component or simply have your program
decompress the sound itself. As before, if you can fit the decompressed sound in
memory, you can use any Sound Manager routine to play it. If you can't, you'll have to
decompress it in chunks and use SndPlayDoubleBuffer or a bufferCmd to play each
chunk. If you write your own 'sdec', of course, you can use any Sound Manager routine
that will play an arbitrarily compressed sound, but be sure to indicate that the sound
is compressed with your compressor so that the Sound Manager will know to call your
'sdec'.
Q How do I make a sound that will play on both Macintosh and PC computers?
A This is actually easy, as long as you don't want to play compressed sounds. We
recommend that you use WAVE files for both systems, since they'll play easily on the
Macintosh. (See the previous answer for some tips to help you play WAVE files on the
Macintosh.) Note, however, that there are many other formats that will work,
including AIFF and QuickTime.
Q How can I access the "Set Utilities Pattern" pattern? (This pattern, used as a
background by certain system utilities like Find File, is normally set by holding down
the Option key in the Desktop Patterns control panel.)
A The Desktop Patterns control panel uses resources of type 'ppat' to store both
desktop and utilities patterns. The 'ppat' resource is stored in the System file in your
System Folder; the desktop pattern has an ID of 16 and the utilities pattern has an ID
of 42. Since this isn't documented, it could be subject to change, so you should be
careful when using it.
Here's a snippet of code that shows how you can get the utilities pattern and then draw
with it:
PixPatHandle ppatHandle;
Rect destRect;
ppatHandle = (PixPatHandle) GetPixPat(42);
if (ppatHandle != NULL) {
SetRect(&destRect, 15, 125, 197, 164);
FrameRect(&destRect);
FillCRect(&destRect, ppatHandle);
DisposePixPat(ppatHandle);
}
Q I discovered that if I hold down the Command key and click in the size box of a
window, I can make the window bigger than the width I pass into GrowWindow. The size
box works as expected when the Command key isn't used. This seems to happen in every
application I've tried. I haven't been able to find any documentation discussing the
relationship between the Command key and the size box. I really need to limit the width
of my windows. Why is this happening and how can I work around it?
A Back in the old days when the Macintosh had a 9-inch screen (384 x 542 pixels),
a lot of developers didn't follow Apple's guidelines for window sizes and hard-coded the
sizeRect given to GrowWindow based on this small size.
When the Macintosh II was introduced in 1987, Apple engineers felt it would be
frustrating for users not to be able to use the whole area of the new 13-inch monitors.
So Apple implemented the "Command-key grow" feature that you discovered, which
allowed users to get whatever size they wanted. However, this feature was not without
consequence to some applications, whose code couldn't handle larger-than-expected
window sizes. The "Command-key grow" feature is documented on page 209 of the old
Inside Macintosh Volume V, but wasn't documented in the newer Inside Macintosh
series.
It's trivial to deal with this feature if you really need to limit the window size: simply
check the size returned by GrowWindow, and if it's larger than you allow, reduce it to
your maximum allowed size before calling SizeWindow.
Q I've noticed that calling DeleteMenuItem mangles the menu data when handling
menu items with strings that have between 251 and 255 characters. Does the Menu
Manager have a problem when handling menu items with strings that long?
A Yes, this is a problem, but it hasn't been documented in any Inside Macintosh
books. The Menu Manager assumes that a menu item string isn't longer than 250
characters, so you shouldn't have menu items longer than that.
Q When I use ShowDragHilite with a picture filling my window, it highlights only the
areas that are the same as the background of my window. Is there any way to fix this?
A Yes. ShowDragHilite isn't very savvy when overlaying image data other than the
background color. The problem lies in QuickDraw's hilite mode. The operation of this
mode is based rather coarsely on the background color. We're working on a fix for this
problem, and eventually hilite mode will work significantly better in all cases,
including that of selecting cells in lists drawn by the standard LDEF. Until then, your
only alternative is to implement your own version of ShowDragHilite.
The question then becomes what color to use. Depending on your circumstances, you
may want to use black, white, or perhaps even inversion, although you should try to
avoid inversion against complex images if at all possible, since it can be ugly and
confusing. Should you decide hilite mode is insufficient, it's up to you to decide how
best to draw your highlight.
Q Sometimes my application's calls to the Drag Manager fail with a -600
(procNotFound) error. This isn't one of the errors listed for these calls. What's up?
A There are three known common causes of this error:
In the last two cases, the Drag Manager has a hard time associating the source window
with a process. Some operations can succeed even without a clear owning process, so
the Drag Manager limps along as well as it can for a while in the hopes that it won't be
asked to do anything that requires a ProcessSerialNumber. When it is asked, the
operation fails.
Q I've just implemented a DragDrawingProc. To start, I've tried simply to duplicate
the default behavior of the Drag Manager (so that it will look as if I had not in fact
attached a DragDrawingProc). Unfortunately, when the user drags into a valid drop
area and the potential drop receiver calls ShowDragHilite, my DragDrawingProc
seems to be responsible for leaving a trail of pixels on the screen. What am I doing
wrong?
A This happens because the Drag Manager doesn't always pass the entire "old" or
"new" region to the DragDrawingProc. Below is a function that mimics what the Drag
Manager does when you don't attach a DragDrawingProc to a DragReference before
calling TrackDrag:
static pascal OSErr LikeDefaultDragDrawingProc(
DragRegionMessage message, RgnHandle showRegion, Point showOrigin,
RgnHandle hideRegion, Point hideOrigin, void *dragDrawingRefCon,
DragReference theDragRef)
{
OSErr err = noErr;
RgnHandle xorMe;
long oldA5;
Pattern gray;
switch (message) {
case dragRegionBegin:
oldA5 = SetA5((long) dragDrawingRefCon);
gray = qd.gray;
SetA5(oldA5);
PenPat(&gray);
PenMode(notPatXor);
break;
case dragRegionDraw:
xorMe = NewRgn();
if (!(err = MemError())) {
XorRgn(showRegion, hideRegion, xorMe);
PaintRgn(xorMe);
}
break;
case dragRegionHide:
PaintRgn(hideRegion);
break;
}
return err;
}
The call to XorRgn is the key. It's also very important to pass the correct value for the
dragDrawingRefCon to SetDragDrawingProc:
SetDragDrawingProc(dragRef, LikeDefaultDragDrawingProc,
(void*)SetCurrentA5());
Note that the above works for 680x0 code; UniversalProcPtr creation has been
omitted for simplicity.
By the way, be careful not to mix the use of SetDragDrawingProc and SetDragImage.
See Technote 1043, "On Drag Manager Additions," for details.
Q When my application calls the Drag Manager's TrackDrag routine and the user
drags text out of my application onto the desktop, a clipping file appears. At least it
does under System 7.5; under System 7.1, nothing happens. Why?
A In Systems 7.1 through 7.1.2, the Drag Manager is implemented by means of
multiple extensions (all in the Extensions folder), and various capabilities become
available according to which extensions are installed. You can't count on any of these
extensions being installed, so if you want your application to use the full functionality
of the Drag Manager under these system versions, your application's installer should
install these extensions.
Some systems may already have older versions of Drag Manager components, in which
case you may want to replace them with newer versions. If you do, be sure to install
all of the appropriate files to ensure version parity on the user's system.
Table 1 describes which components implement which functionality on which system.
It's provided only for purposes of installation. Your application should not attempt to
determine what functionality is available according to which files are installed (since
users may have enabled some extensions without restarting, and since different
versions of the system require different sets of extensions). Your application should
instead test for Drag Manager functionality with the gestaltDragMgrAttr Gestalt
selector.
______________________________
Table 1. Drag Manager files required for individual features
Feature
Interapplication drag and drop
Drag and drop to/from Finder
Clippings
Note: You should not install Finder 7.1.3 on user systems; in fact, there isn't an
easily available license for shipping it. However, before System 7.5 it was the only
way for developers without System 7 Pro (which includes Finder 7.1.3) to debug
their code, so its use is documented here for historical reasons.
______________________________
In System 7 and 7.0.1, the Drag Manager is supported, but only for intra-application
dragging. This makes it less desirable to install the required Macintosh Drag and Drop
extension, because it provides nothing that can't be implemented through judicious use
of QuickDraw, the Window Manager, and OSEventAvail.
In System 7.5, the picture is equally simple but significantly richer. All Drag
Manager functionality is built into or installed with the system.
Q Under MacTCP and Open Transport 1.0.x, if I'm using a Hosts file and I call
AddrToName, the name resolves to the correct address. Under Open Transport 1.1 it
returns an authNameErr. What's going on?
A Open Transport version 1.0.8 mapped name-to-address and address-to-name
translations into the same cache, and searched the cache whenever either a
name-to-address or an address-to-name mapping was requested. Sounds good, right?
The problem is, it broke several server load-sharing implementations that registered
a service name as a single alias for a list of CNAMEs, each of which pointed to a server
running the service. Under the former caching scheme, load-sharing techniques that
depended on reverse lookups didn't work for the Macintosh -- they'd always wind up
with the same host name and hardware address for the original alias.
As a result, Open Transport 1.1 no longer caches address-to-name mappings (PTR
records), nor does it search the name-to-address cache for address-to-name requests.
(The treatment of CNAME records received was also modified, but that's irrelevant to
your question.) Instead, it queries the configured domain name servers; apparently
you got no authoritative information from any of them (or perhaps you weren't using
them at all).
Strictly speaking, the behavior you're now seeing is more correct than what you saw
before. DNS A resource records map names to addresses. To map an address to a name,
you need a PTR record. The previous behavior of the MacTCP and Open Transport
TCP/IP DNRs, treating the one as the mirror image of the other, was incorrect and has
been changed accordingly.
The Macintosh Hosts file historically did not support PTR records, and does not
support PTR records now. To do so, those records would have to be cached, once again
breaking the load-sharing schemes. The only resource records the Hosts file supports
are: A (name to address), CNAME (alias to fully qualified domain name), and NS
(domain name server's fully qualified domain name). If you need a PTR mapping, you
must register it with your local domain name server administrator, or maintain it
within your own code from the results of your earlier name-to-address request.
Q I'm writing an application using the native Open Transport APIs. My original
intention was to ship only a 680x0 version of the application, but I've heard that this
won't be compatible with future versions of Open Transport. Is this true?
A Yes. We strongly recommend that you ship all native Open Transport applications
as fat applications for maximum speed and compatibility.
Under System 7, Open Transport provides native APIs for both 680x0 and PowerPC
clients. This allows 680x0 Open Transport clients to operate under emulation on a
Power Macintosh. This won't be supported under future systems because they won't
support the Apple Shared Library Manager, the dynamic linking technology used by
680x0 Open Transport clients. Table 2 summarizes this information.
______________________________
Table 2. Open Transport compatibility
| Open Transport version | 680x0 | 680x0 | PowerPC |
| client | client | client | |
| on 680x0 | on PowerPC | ||
| Open Transport 1.0.x | N/A (1) | Yes (2, 3, 4) | Yes |
| Open Transport 1.1, System 7 | Yes | Yes | Yes |
| Open Transport 1.5, System 7 | Yes | Yes | Yes |
| Open Transport, future systems | N/A (5) | No (6) | Yes |
Notes:
______________________________
Q What are the different Gestalt selectors for MacTCP, Open Transport, and
AppleTalk?
A The Gestalt selector for MacTCP is 'mtcp'. MacTCP versions 1.0 through 1.0.3
didn't register this selector. Versions 1.1, 1.1.1., and 2.0 return 1, 2, and 3,
respectively. If Open Transport is installed, 4 is returned. A value of 0 is returned if
the driver is not opened.
The Gestalt selectors for Open Transport are gestaltOpenTpt and
gestaltOpenTptVersions. You can test whether Open Transport and its various parts are
available by calling the Gestalt function with the gestaltOpenTpt selector. The bits
currently used are defined by constants in OpenTransport.h, as follows:
enum {
gestaltOpenTpt = 'otan',
gestaltOpenTptPresent = 0x00000001,
gestaltOpenTptLoaded = 0x00000002,
gestaltOpenTptAppleTalkPresent = 0x00000004,
gestaltOpenTptAppleTalkLoaded = 0x00000008,
gestaltOpenTptTCPPresent = 0x00000010,
gestaltOpenTptTCPLoaded = 0x00000020,
gestaltOpenTptNetwarePresent = 0x00000040,
gestaltOpenTptNetwareLoaded = 0x00000080
};
If Gestalt returns no error and responds with a nonzero value, Open Transport is
available. To find out whether Open Transport AppleTalk, TCP, or NetWare is present,
you can examine the response parameter bits as shown above. For example, if you pass
the gestaltOpenTpt selector to Gestalt, a result of 0x0000001F means that Open
Transport is present and loaded, the AppleTalk protocol stack is also present and
loaded, and the TCP protocol stack is present but not loaded.
The gestaltOpenTptVersions selector is used to determine the Open Transport version
in NumVersion format. For example, passing the gestaltOpenTptVersions selector
through a Gestalt call or MacsBug to Open Transport version 1.1.1b9 yields a result of
0x01116009. (Note that Open Transport versions 1.0 through 1.0.8 did not register
this selector.) For more information on Apple's version-numbering scheme and the
NumVersion format, see Technote OV 12, "Version Territory."
For AppleTalk, the Gestalt selectors are 'atkv' (no constant defined) and
gestaltAppleTalkVersion. The gestaltAppleTalkVersion selector was introduced in
AppleTalk version 54 to provide basic version information. Calling Gestalt with this
selector provides the major revision version in the low-order byte of the function
result. For example, passing the gestaltAppleTalkVersion selector in a Gestalt call or
through MacsBug with a result of 0x0000003C means that AppleTalk version 60 is
present. (Note that the gestaltAppleTalkVersion selector is not available when
AppleTalk is turned off in the Chooser.)
The 'atkv' Gestalt selector was introduced as an alternative in AppleTalk version 56 to
provide more complete version information via the 'vers' resource. For example,
passing the 'atkv' selector to AppleTalk version 60 through a Gestalt call or MacsBug
yields 0x3C108000.
Q I'm writing an Open Transport module that conforms to the Transport Provider
Interface (TPI). I find that Open Transport passes data to my TPI module using
M_DATA message blocks, rather than M_PROTO message blocks with PRIM_type being
T_DATA_REQ. What's going on?
A The answer can be found at the end of the description of T_DATA_REQ in Appendix
A-2 of STREAMS Modules and Drivers (UNIX Press, 1992):
The transport provider must also recognize a message of one or more M_DATA
message blocks without the leading M_PROTO message block as a T_DATA_REQ
primitive. This message type will be initiated from the write (BA_OS)
operating system service routine.
Open Transport deliberately uses this variant behavior as an optimization. By using
M_DATA, it avoids allocating a buffer for the M_PROTO header. Since every memory
allocation takes time, avoiding this one makes the system faster.
This behavior isn't seen on expedited data because the specification doesn't allow for
this optimization on T_EXDATA_REQ.
Q How can I launch a "foreground" task to run in the background?
A You should use the LaunchApplication call in the Process Manager with the
launchDontSwitch flag set in the launchControlFlags field. For more information about
LaunchApplication, see Inside Macintosh: Processes, Chapter 2.
Q Tackling a difficult problem in my application had put me in a foul mood, when a
colleague pointed out that I was being awfully "tetchy." I told him the correct word is
"touchy," and sure enough my spelling checker doesn't recognize "tetchy." Who's
right?
A Your colleague wins this one. The Oxford English Dictionary does recognize
"tetchy," which means "easily irritated or made angry." It lists many variants for the
spelling of this word, including techy, techie, teachy, teechy, tetchie, tecchy, titchie,
tichy, titchy, tertchy, tatchy, and tachy.
These answers are supplied by the technical gurus in Apple's Developer Support
Center. For more answers, see the Technical Q&As on this issue's CD or on the World
Wide Web at http://www.devworld.apple.com/dev/techqa.shtml. (Older Q&As can be
found in the Q&A Technotes, which are those numbered in the 500s.)*