Macintosh Q & A

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:

• The use of high-level debuggers -- Since the Drag Manager interacts heavily with the Process Manager, as does the typical high-level debugger, conflicts inevitably develop. There's no workaround for this problem except to ask your debugger vendor to improve the debugger's behavior when debugging Drag Manager code. If your code is encountering such a problem, it should run fine when the debugger is not involved.

• Passing TrackDrag an event record whose where field is expressed in local coordinates -- Such where fields often point outside the window in which the drag originates. (This can also cause a crash, but sometimes simply results in a -600 error.)

• Attempting to use the Drag Manager with Text Services Manager windows when the gestaltDragMgrFloatingWind bit isn't defined in the response to the gestaltDragMgrAttr Gestalt selector -- The value of this bit denotes whether a Drag Manager bug with TSM windows is fixed on the system your application is running under.

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

• System 7.1
• System 7 Pro (7.1.1)
• System 7.1.2

Interapplication drag and drop

• Macintosh Drag and Drop, Dragging Enabler
• Macintosh Drag and Drop
• Macintosh Drag and Drop

Drag and drop to/from Finder

• Macintosh Drag and Drop, Dragging Enabler, Finder 7.1.3
• Macintosh Drag and Drop, Dragging Enabler
• Macintosh Drag and Drop, Dragging Enabler, Finder 7.1.3

Clippings

• Macintosh Drag and Drop, Dragging Enabler, Finder 7.1.3, Clipping Extension
• Macintosh Drag and Drop, Clipping Extension
• Macintosh Drag and Drop, Dragging Enabler, Finder 7.1.3, Clipping Extension

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:

1. Open Transport 1.0.x was never shipped or supported on any 680x0 Macintosh.

2. You must link with the Open Transport 1.1b6 or later libraries for this to work.

3. Obviously you must not call routines that were introduced with Open Transport 1.1.

4. Support for 680x0 clients on PowerPC isn't well tested under Open Transport 1.0.x. For this and many other reasons, you should implore your users to upgrade to 1.1.

5. Future systems will be PowerPC only.

6. Future systems won't support ASLM, so it's not possible for it to support Open Transport 680x0 clients.

---

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