MACINTOSH Q & A

Macintosh Developer Technical Support

Q I want to write an application that can open incoming PowerTalk letters automatically. How can my PowerTalk-savvy application access the letters stored in the in-tray?

A Currently, there are only two ways of accessing in-tray letters from your application. The most common method is to receive an open document ('odoc') Apple event when a letter is opened from the Finder. In addition, calling SMPGetNextLetter allows you to open letters from your application. It isn't possible, however, for your application to access the in-tray from Standard File or to automatically open arbitrary letters without user intervention.

Q When I open a letter in my PowerTalk-savvy application, I can obtain FSSpec records referencing folders or files enclosed in the letter, but the files don't appear to be copied to my hard drive. Where do these files reside on my system?

A PowerTalk maintains an external file system for enclosures of letters. If you closely examine the FSSpec records returned to you, you'll see that the enclosed files and folders reside on this external file system, named "Mail Enclosures." This is a read-only file system, and the enclosures are available only while the letter is open. Therefore, these FSSpecs should be used only to copy the enclosed items to your local disk, and all references to them should be discarded by the time you call SMPDisposeMailer.

Q When I call FrontWindow from within a VBL task, my system occasionally freezes at this call. Is there any chance that it moves memory?

A No, but FrontWindow is not reentrant. It's been patched out since MultiFinder, and ought to be on the list of routines that shouldn't be called at interrupt time. You'll have to come up with another method of getting the front window from your VBL task. You may want to keep a shadow copy of your application's window list in your application global area where your VBL task can get to it.

Q We want a general extension for all PAP-capable printer drivers, to allow for user authentication at print time. It would conduct a user authentication dialog with a spooler on the order of the one described in Chapter 14, "Print Spooling Architecture," of Inside AppleTalk, Second Edition. Is it possible to do this in the QuickDraw GX printing architecture? Would we do anything different for PostScript-savvy print spoolers to insert the right document-structuring comments?

A For spoolers that are PostScript-savvy, you can override the message GXPostScriptDoDocumentHeader from a printing extension and insert your password information in the PostScript header at that point, including password, user name, and so on. When your spooler receives the job, it can check this data and see if it denotes a valid user. By overriding this message you'll work with any PostScript driver, as long as your spooler supports it. (You're actually talking only to your spooler, not to the different drivers.)

For the authentication, you'll need to override GXOpenConnection to get the user's name and password, since that's when you actually try to connect to the device or spooler. You could use cool alerts (status dialogs) to get the information from the user at that time. Be sure not to put up a "Type in your password, please" dialog except at device communication time. At other times, the user won't be trying to connect to the device and shouldn't need to provide authentication.

Q We plan to convert all our QuickDraw objects to QuickDraw GX objects when we print, then use a QuickDraw GX printing loop to print our objects. We print bitmaps at the printer's maximum resolution, through PrGeneral. How do we print bitmaps at the printer's maximum resolution in QuickDraw GX? How do we find the printer's maximum resolution?

A To print bitmaps at the printer's maximum resolution in QuickDraw GX, create the bitmaps at the desired resolution (like 300 dpi) and then put a transform on the shape to scale it by 72 divided by the bitmap's resolution. This method makes the bitmap show up with the correct dimensions, whether it's drawn on a 72-dpi screen or a 300-dpi printer. And, on the 300-dpi printer, the bitmap will not be scaled at all -- it will render at 300 dpi. This works because, before drawing, the shape's scaling is multiplied by the device's resolution divided by 72, to convert the shape to device resolution.

To find a printer's maximum resolution, use the calls to get the information from the printer's view device list (get the printer from the job via GXGetJobPrinter), pick the highest-resolution printing device, and voilà!

Q My application won't print to a StyleWriter II although it works fine on all other printers, including the original StyleWriter. Can you give me any suggestions? What's different about the StyleWriter II?

A The StyleWriter II driver is a member of the "GrayShare" driver family, with new features such as support for grayscale printing (if Color QuickDraw is available) and printer sharing over the network. Its internal architecture is very different from previous printer drivers. In spite of thorough compatibility testing, some problems have shown up since the first release. In many cases, the driver revealed weaknesses in the applications themselves; for some other problems, a solution will be incorporated in the next release of the driver. Here are some identified problem areas with GrayShare drivers (note that these don't necessarily represent bugs in the drivers, but are differences in the system's configuration at print time):

• GrayShare drivers handle memory differently. For example, if an application has a dereferenced handle to an unlocked block while doing a CopyBits into the printing port, this may work fine on other printer drivers, but the block is likely to move with a GrayShare driver and the results are unpredictable.
• GrayShare drivers maintain their own A5 world internally. If an application installs a growZone proc and forgets to set up its own A5 in the growZone proc -- ignoring the Macintosh Technical Note "Register A5 Within GrowZone Functions" (Memory 1) -- the growZone proc may get called with a GrayShare driver's A5, which obviously is bad for the survival of both the application and the printer driver.
• GrayShare drivers call the pIdleProc (in the job subrecord of the print record) more often than other printer drivers; in particular, it may be called during execution of PrOpenDoc. If an application reloads a previously used print record containing an old (now invalid) pointer to a pIdleProc and doesn't update the pIdleProc field before calling PrOpenDoc, disaster is very likely. Note that Macintosh Technical Note "pIdle Proc (or how to let users know what's going on during print time...)" (Printing 22) recommends installing your pIdleProc before PrOpenDoc.
• Like most other QuickDraw printer drivers, GrayShare drivers use algorithms built into QuickDraw for rasterizing picture elements like ovals and arcs, but not necessarily with the same sequence of coordinate transformations. Because of the 360 dpi resolution, internal computations with the transformed coordinates may hit the 16-bit integer limitation of QuickDraw and reveal bugs in the old QuickDraw routines that have remained hidden until now.
• Some GrayShare drivers (like the StyleWriter II driver, version 1.0) contain STR# resources with positive ID numbers that may conflict with STR# resources in an application. This will be fixed in the next release of the drivers.
• Under certain circumstances, GrayShare drivers seem to have trouble with the PmForeColor call. This is under investigation and will be fixed.

Q We've been manually writing 'PAPA', 'STR ', and 'alis' resources in the System file and in the LaserWriter driver to change printers without using the Chooser. This method sometimes causes errors with LaserWriter 8. What do we need to do?

A LaserWriter 8 needs to know more about the printer than its AppleTalk name -- it also has to have a PostScript printer description (PPD) file for that printer, parsed and ready to be used. Since there's so little memory available in applications like the Finder during printing, the parsing is done at Chooser time, not at print time.

Apple has always said "We can't guarantee that you can change printers behind the Chooser's back," and with LaserWriter 8 this is true. If the driver has parsed a PPD file and has it ready, things should work OK, but everything must have been manually set up by choosing that printer ahead of time. If you set up a LaserWriter IINTX printer with the correct PPD file, choose a LaserWriter IIf, and then choose another printer driver, you could probably programmatically switch back to the LaserWriter IINTX, but the driver will use the LaserWriter IIf PPD file with it, which might or might not produce the right behavior. Designing the driver to be switchable by other applications simply wasn't a priority of the Adobe/Apple development team.

As long as you try to switch to a printer that uses the same PPD file that the driver last parsed (meaning the PPD associated with the last printer selected in the Chooser), there shouldn't be any more problems than there were before.

Q I want to create a QuickDraw GX font that will calculate check digits as the user types the numbers in. For example, if you type "123458723" the check digit would be 5; if you type "098732734" the check digit would be 7; and so on. The formula is check digit = sum of nine numbers MOD 10; the check digit is appended as the number's tenth digit. Is there a way to do this using the glyph modification properties in QuickDraw GX? I know it can be done by creating an entry in the 'mort' table for all unique possibilities, but there are 9 ^9 possibilities, which comes to 387,420,489. Can I enter a formula instead of creating tables? If so, how?

A It's a fascinating idea, but it's not something the 'mort' tables can handle. These tables are basically state machines; when they detect a particular state, they take some action based on entries in the table. There's no way to add a formula or code in any language to these tables.

All the tables can do is take a series of glyphs and replace them with a different glyph if a given feature is enabled by line layout. For example, you can change the two letters "f"and "i" into the corresponding ligature"fi" (one glyph). If you wanted to do this for check digits, you'd have to have an entry in the 'mort' table for each glyph combination you wanted substituted. For 300000000, you'd have to have one entry that substituted 3000000003, and the substitution has to be one glyph. Since order is significant, that means you'd have to have one billion entries in the 'mort' table and one billion glyphs representing all the entries with their check digits added. That's where we have to stop, because a font can't contain more than 65,536 separate glyphs. It's a really neat idea, but it won't work.

Q I've selected AppleShare volumes to mount at system startup by checking the volumes in the Chooser list. If I'm on a nonextended network and I call an extended network via AppleTalk Remote Access and log into a remote server via the Chooser and AppleShare, an error alert will say "The AppleShare Prep file needed some minor repairs. Some AppleShare startup information may be lost." All the information about my local nonextended network will be cleared out of the AppleShare Prep file. So I lose all my log- in IDs and passwords for my local servers. The same thing happens going back the other way (extended to nonextended). Why is this happening?

A There are several problems you can run into when you connect two networks (which is what you're doing when you use AppleTalk Remote Access when you're already connected to a network). The problems are usually the result of duplicate names or duplicate node numbers.

The "boot mount list" (BML) kept in the AppleShare Prep file stores the location of volumes that you want mounted at boot time. Part of that location is the zone name. If you create BML entries when you aren't on an extended network -- that is, when you have no zones -- the zone name stored in the BML is "*" (AppleTalk's shorthand for "this zone"); otherwise, the zone name of the server is stored in the BML.

The boot mounting code checks the validity of the BML when the system starts up, and the AppleShare Chooser package checks the validity of the BML when it's opened. If there are no zones, entries with zone names other than "*" are cleared and the alert "The AppleShare Prep file needed some minor repairs. Some AppleShare startup information may be lost" is displayed because those entries aren't valid. If there are zones, entries with zone names of "*" are cleared and the alert is displayed because the "*" zone name isn't a reliable way to save the zone location of a server on an extended network. The "*" zone isn't reliable for storing the zone name because a workstation can easily be moved from zone to zone, keeping the same NBP object and NBP type names. This is especially true with AppleTalk Phase 2, which supports multiple zones on a single network (for example, multiple zones on the same piece of Ethernet cable).

The workaround for boot-mounting volumes is to create alias files to the file servers you want to mount at boot time and then drop those alias files into the Startup Items folder inside your System Folder. The only drawback to this is that aliases don't save the user's password. If you need boot-mounted volumes without the password dialog, you'll have to use guest access.

Q What is a Macintosh IIvm? One of the System Enabler files defines the computer in gestaltMachineType 45. Is this just another name for the Performa 600? The Macintosh IIvx Developer Note says that the Performa 600 returns type 45.

A Apple had planned to release a model called the Macintosh IIvm but consumer testing showed that users thought "vm" was an abbreviation for "virtual memory." This was about the same time Apple was about to introduce the Performa line. So, to avoid confusion, the model became the Performa 600. There are, therefore, three models in the "v" series: the Macintosh IIvi, Performa 600 (Macintosh IIvm), and Macintosh IIvx. As you can see, using the nonreleased "Macintosh IIvm" designation confuses people, so try to avoid it.

Q What do those numbers at the end of System Enabler file names mean?

A If you hold down a certain modifier key combination while opening your System Folder, the System 7.1 Finder will reward you with a special message from Apple's Advanced Technology Group -- if and only if the current tick count (as returned by TickCount) divided by the number at the end of the machine's enabler file name (in decimal) is exactly equal to the model number of the Macintosh for which the enabler is intended.

Legal restrictions prevent us from revealing the message itself, but enterprising techno-nerds may attempt to find it with these instructions.

Q Which variables does the stack sniffer VBL task look at to determine that the stack has crossed over into the heap? I create stacks for my own subtasks in the heap. Will modifying those variables affect anything else besides the stack sniffer? What's the correct process to defeat the stack sniffer task (leaving it installed) or remove the task?

A Disabling the stack sniffer is reasonably simple -- storing four bytes of $00 in the low-memory global StkLowPt ($110) will turn the sniffer off. However, when using your own internal stack, be sure not to call any Toolbox routines, because many of them rely on the stack for temporary storage, which will screw things up if you've played with the value of register A7.

When you're using your own stack within your heap, you should definitely save the values in StkLowPt and A7 before changing them, so that you can reset their values before and after any Toolbox calls.

Q How can I tell whether a picture is QuickTime-compressed?

A The key to your question is "sit in the bottlenecks." If the picture contains any QuickTime- compressed images, the images will need to pass through the StdPix bottleneck. This is a new graphics routine introduced with QuickTime. Unlike standard QuickDraw images, which only call StdBits, QuickTime-compressed images need to be decompressed first in the StdPix routine. Then QuickDraw uses StdBits to render the decompressed image. So swap out the QuickDraw bottlenecks and put some code in the StdPix routine. If it's called when you call DrawPicture, you know you have a compressed picture. To determine the type of compression, you can access the image description using GetCompressedPixMapInfo. The cType field of the ImageDescription record will give you the codec type.

See the CollectPictColors snippet on this issue's CD and "Inside QuickTime and Component- Based Managers" in develop Issue 13, specifically pages 46 and 47, for more information on swapping out the bottlenecks.

Q Is there a way to embed a QuickTime movie into a Macintosh file containing non-QuickTime stuff and get the Movie Toolbox to play the movie back correctly? If so, can we pass the same movie handle to QuickTime for Windows and get it to play back the same data from the same file?

A To add QuickTime movie data to non-QuickTime files, just store the movie data in the file using FlattenMovieData with the flattenAddMovieToDataFork flag. Since FlattenMovieData will simply append to a data fork of a file, you can pass it any data file and it will append the movie data to that file. QuickTime doesn't care what's stored before or after the movie data, as long as you don't reposition the movie data within the data file. If you do, the movie references will be incorrect since they aren't updated when you edit the file. The returned movie (from FlattenMovieData) will properly resolve to that data file. You can then save this movie in the data fork with PutMovieIntoDataFork or in the resource fork with AddMovieResource. If the movie is saved in the data fork, it can be retrieved by both QuickTime and QuickTime for Windows with NewMovieFromDataFork.

You can, in fact, store multiple movies simply by calling FlattenMovieData and PutMovieIntoDataFork several times on the same file. Each FlattenMovieData call appends new data, assuming the createMovieFileDataCurFile flag isn't set.

Q Is there a way that the action filter procedure of a QuickTime movie controller component can have a user reference field so that I can know which movie "object" the movie controller refers to? There are local variables associated with a particular movie that I would like to access from the action filter procedure; currently there's no way to reference back to the variables in my program except through globals.

A This was a difficult task under QuickTime 1.0, requiring you to stuff some sort of pointer in the movie user data fields. The good news is that in response to developer requests, starting with version 1.5, QuickTime includes a new call in the Movie Controller suite allowing you to pass and receive a long value when you set up your filter procedure, as follows:

pascal ComponentResult MCSetActionFilterWithRefCon(MovieController
                            mc, MCActionFilterWithRefCon
                            myUserPlayerFilter, long refCon) =
                            {0x2F3C,0x8,0x2D,0x7000,0xA82A};

The procedure is of the form

pascal Boolean userPlayerFilter(MovieController mc, short action,
                                    void *params, long refCon);

The procedure returns true if it handles the action, false if not. The action parameter identifies the action to be executed; params is the set of potential parameters that go with the action; and refCon is any long value passed to MCSetActionFilterWithRefCon.Q We want to add temporal compression for our long movies with similar sequential frames. How do I use the Compression Manager routines (CompressionSequenceBegin and CompressSequenceFrame, for instance) in conjunction with the normal movie-making routines (such as CompressImage)?

A Sequence compression is useful for temporal compression, with processes like animation. Sequence compression works by providing one description handle for a series of frames, whereas CompressImage may use a description handle for each image. Thus, functions such as CompressImage are normally used separately from the sequence calls. It's a bit confusing; the Movie Construction FD sample on the QuickTime CD should help clarify how to use the calls.

Sequence compression performs similarly to creating a movie with CompressImage, but the major difference is the specification of key frames. (Key frames are frames against which all the following frames are differenced.) CompressSequenceFrame returns a similarity value, which tells you whether the frame is a key frame (0 means key frame). Based on this value, you can tell AddMediaSample the type of frame it is. Here's some pseudo code:

err = CompressSequenceFrame(seqID, ..., similarity, nil);
err = AddMediaSample(gMedia, ..., similarity ? mediaSampleNotSync :
        0, &sampTime);

Q When we try to digitize frames (grabbed with QuickTime) into an off-screen pixel map, our VDGrabOneFrame call crashes. How would you suggest we do this?

A You need to check whether the 'vdig' resource supports digitizing off-screen by calling the PreflightDestination routine. If the PreflightDestination call with an off-screen destination fails, you need to digitize to a window on the digitizing device and then copy the image (using CopyBits or your own algorithm for speed) from the window to your off-screen pixel map. Some 'vdig' resources don't support digitizing directly to off-screen pixel maps because their hardware does the digitizing asynchronously. You should always preflight your destination before setting it with SetPlayThruDestination.

Q Why doesn't the QuickDraw GX LaserWriter driver have a 'pdip' resource? Isn't it required? ?

A A 'pdip' resource isn't required; if it isn't present in the driver, the default (LaserWriter Plus) preferences are used. Those preferences are currently as listed below. They're subject to change, so don't depend on them. If you need a specific value for any of these preferences, just include your own 'pdip' resource.

Q Inside Macintosh: Macintosh Toolbox Essentials recommends calling CloseDialog instead of DisposeDialog when allocating memory for a dialog record manually instead of letting the Toolbox do it. But doing so causes a memory leak, because GetNewDialog copies the DITL resource in memory. The DITL copy isn't released by CloseDialog and isn't purgeable, even if the original DITL was purgeable. What's the official method of completely getting rid of a dialog whose storage you've allocated by hand?

A CloseDialog was intended to mirror NewDialog; it allows you to close a dialog that you provided the storage for, including the item list. Page 6-119 of Inside Macintosh: Macintosh Toolbox Essentials states that the item list is specifically not disposed of by CloseDialog, so it's acting as documented. It does this so that it won't dispose of a dialog item list you might be planning to use again. If you do want to dispose of the item list, just do so after calling CloseDialog.

Q As a MacApp developer, am I supposed to be using the .h files in the MPW:Interfaces folder, or the ones in the {MacApp}CPlusIncludes folder?

A As a default, MacApp 3.0 first searches through the {MacApp}CPlusIncludes folder for header files specified in your source, so we suggest using the CPlusIncludes headers. The path to these include files is defined in the {MacApp}Startup Items:Startup folder. MacApp 3.1 uses the universal interfaces for both 680x0 and PowerPC development. It no longer uses its own custom headers in the {MacApp}CPlusIncludes folder. MacApp 3.1 searches MPW's {CIncludes} folder for its headers.

Q When starting a new MacApp program, I get the message "Couldn't create new document because an internal component is missing. Please contact the developer." How do I find out which component is missing?

A When building an application, the linker strips out any unused code from the final application. The problem is that it determines which code is to be stripped out by finding all objects that are constructed with the new operator. Because objects derived from TView might instead be instantiated through calls to TViewServer methods, the linker thinks that calls to your derived TView objects aren't used, so those objects are stripped from the build. To circumvent this, you have to fool the linker into not stripping out this code. MacApp defines a macro that makes it easy for you to trick the linker. Place this line of code in your implementation of TSomeApplication::ISomeApplication:

macroDontDeadStrip(TSomeView);

Do this for any subclass of TView defined in your program. Good examples of the use of this routine can be found throughout the MacApp C++ code.

MacApp takes care of this for you for any TView subclasses defined by MacApp, provided you call InitUDialogs, InitUTEView, and so on in your main routine. The exact set of routines you have to call depends on the TView classes you use in your application. All of these routine names begin with "InitU."

MacApp uses two alerts to indicate that you're missing components. The first one ends with "because an internal component is missing. Please contact the developer." The second one is identical except that it's preceded by the class name of the missing component. In the former case it's very likely you forgot one of the "InitU" calls; in the latter case you're very likely missing a macroDontDeadStrip on one of your TView subclasses. If you need to find out more precisely which components are missing, you can break on the Failure routine with a debugger.

Q How many new Inside Macintosh books will there be by the time all the new technologies are documented?

A How much shelf space do you have?

These answers are supplied by the technical gurus in Apple's Developer Support Center. Special thanks to Sonya Andreae, Mark Baumwell, Brian Bechtel, Chris Berarducci, Matt Deatherage, Tim Dierks, Steve Falkenburg, Nitin Ganatra, Bill Guschwan, Dave Hersey, Jim Luther, Joseph Maurer, Kevin Mellander, Martin Minow, Eric Mueller, Ed Navarrete, Mike Neil, Guillermo Ortiz, Jeroen Schalk, Brigham Stevens, Dan Strnad, and John Wang for the material in this Q & A column.

Extra special thanks and a fond farewell to Rilla Reynolds, who took a thankless job and made it work for all of us. *

For more information on LaserWriter 8, see this issue's "Print Hints" column. *

For more information on universal interfaces, see the article "Making the Leap to PowerPC" in this issue. *

Have more questions? Need more answers? Take a look at the Macintosh Q&A Technical Notes on this issue's CD and in the Dev Tech Answers library on AppleLink. *