Technical Note TB535

Finder Q&As

CONTENTS Downloadables

This Technical Note contains a collection of archived Q&As relating to a specific topic--questions sent the Developer Support Center (DSC) along with answers from the DSC engineers. Current Q&A's can be found on the Macintosh Technical Q&A's web site. [Sep 01 1993]

How to get Finder Label menu colors and labels

Where can an application find the colors and labels the Finder uses in the Label menu?

The GetLabel call returns the color and string used in the Finder's label menu. This call is described in the Macintosh Technical Note "Drawing Icons the System 7 Way."

The interface to the call is:

pascal OSErr GetLabel(short labelNumber,
              RGBColor *labelColor,
              Str255 labelString)

A couple of interesting facts that you might find useful: labelNumber is zero based with zero pointing to the "none" label; the other values, one through seven, refer to the real labels in reverse order (Don't ask why!) with 1 returning "Project 2" and 7 returning "Essential." The information returned also applies to the Labels control panel.

Back to top

Determining whether a file is in the trash under System 6

Date Written: 12/22/92

Last reviewed: 6/14/93

How do I determine whether a file is in the trash under System 6? Inside Macintosh says that FInfo.fdFldr contains -3 if the file is in the trash but my tests show that fdFldr always contains zero. Under System 7 it's easy to tell whether a file is in the trash, of course.

Under System 6, the only way the Finder remembers that a file is in the trash is by maintaining an internal list of the files in the trash. Nothing is changed about that file to indicate that it's in the trash. This is why the System 6.0.x Finder can't remember the contents of the trash across a launch or restart, because the only memory of the fact that these files are in the trash is in RAM. (For example, throw a file away and then restart the machine by pressing the interrupt switch on the programmer's switch. When the machine is done restarting, you'll find that the file isn't deleted at all; it's exactly where you left it.)

The fdFldr field described in Inside Macintosh Volume II is used only under MFS, where folders were only a Finder construct because the file system didn't support hierarchical organization. It became unused on HFS disks and is always zero.

Back to top

System 7.1 Fonts folder selector is "font"

Date Written: 11/4/92

Last reviewed: 6/14/93

Is there a constant for the System 7.1 Fonts folder that I can use with the FindFolder call to locate the folder? The include file supplied with System 7.1 doesn't define a constant for the Fonts folder.

Looks like an oversight--the selector should be included in the header files for System 7.1. You can use the selector "font" with the FindFolder routine to locate the System 7.1 Fonts folder.

These selectors are stored in the system resource file, of type 'fld#', so you can always look there for new constants in the future.

Back to top

Use Mac Finder for application file & folder icon placement

Date Written: 5/31/91

Last reviewed: 8/1/92

When my Macintosh program creates a file in the Desktop folder, how can I get it to appear where the Finder would place it on the desktop?

Don't set the "INITed" bit when you create your file or folder, and the Finder will take care of icon placement for you.

You should not attempt to place the icon behind the Finder's back, although the icons' positions within the folder relate to where they appear on the desktop. You will have a hard (or impossible) time with icon placement, since you don't have access to the private Finder data structure where the positions of the volume icons are stored. You are better off letting the Finder handle placement. Making assumptions about the way the Finder works internally is a bad idea.

Back to top

Forcing the Macintosh Finder to update the desktop

Date Written: 5/14/90

Last reviewed: 8/1/92

How do I force the Macintosh Finder to update its windows after my application has changed a file's FndrInfo?

There is no direct way to tell the Finder to update the desktop. The Finder will synchronize the desktop file's appearance after it detects that a change has been made for a volume. This is triggered when the volume's modification date changes, which occurs when you create or delete a file, for example, or move it to another folder. When a change occurs, HFS will change the modification date of the volume and that folder. When the Finder notices that the volume's modification date has changed, it begins scanning for changes in all of the open folders. This scanning process takes place about once every 10 seconds.

Changing the file's FndrInfo or renaming the file does not change the modification date. As a suggestion for an installer program, you could initially create a temporary file, and then, once all the files are installed, delete the temporary file. Deleting the temporary file as a last step will cause the Finder's window to be updated.

Back to top

How often the Macintosh Finder updates its internal information

Date Written: 5/3/89

Last reviewed: 8/1/92

The Macintosh Finder doesn't always show changes my program makes to file sizes and attributes until I close and reopen the window.

The Finder updates its internal information every 10 seconds, and/or whenever a folder is opened. It may not notice some changes unless the folder's modification date is changed.

Back to top

Controlling which application version is launched by Finder

Date Written: 11/27/90

Last reviewed: 6/14/93

We have several versions of a Macintosh application (standard, demonstration, student, and so on) and they all share the same type ('APPL') and creator bytes. When we have all of the versions on a hard disk, double-clicking on a document launches the demonstration version rather than the full version. Is the system's application choice based on its date of creation, name, or other attribute? How can a user specify which of several versions s/he wishes to launch when double-clicking on a document? Alternatively, what can we as developers do to designate the standard version as the one to be launched if there are other versions on the disk?

Under System 6, the Finder adds information about the last application copied to a disk to the disk's Desktop file, and that application is used for opening documents with the appropriate creator type.

Under System 7, the Desktop Database maintains a list of the disk's applications, and when asked (via the call PBDTGetAPPL) specifically returns as the "preferred" application on a volume the one with the appropriate creator type and most recent creation date. Make certain that the desired application has the most recent creation date before users copy it to their hard drives. For more information about the Desktop Database under System 7, see the Finder Interface chapter of Inside Macintosh Volume VI.

Back to top

Using 'dast' resource to display "About..." DA under System 7.0

Date Written: 11/7/90

Last reviewed: 6/14/93

I'm upgrading my desk accessory to be more compatible with Macintosh System 7.0, but I'm unable to get anything to display in "About..." using the Alarm Clock's 'dast' resource. What do I need to change?

The 'dast' resource will be used only if the system thinks your DA is System 7.0-friendly. The way to convince it of this is to add a BNDL and FREF resource into your DA file, along with the appropriate signature string (just like an application would have done). You then make sure that all of these resources are owned by the DRVR. This can be done in the GetInfo window of ResEdit. The only resource that should be special is the signature resource which should still have a resource ID of 1. Once all of this is done, set the Bundle flag, and clear the INITed flag (also using ResEdit) to get the Finder to notice the changes. At this point, your DA should have the correct icons, and should also display the dast string in your about box. To make it easy, just copy all of the resources including the ICN# and icXX resources out of the Alarm Clock file, and then make them owned by your driver. If your DRVR resource has the same ID as the Alarm Clock, all you have to do is copy them over. Once the system starts using them, you can simply use ResEdit to edit the icons. This way you will have the appropriate icon in the Apple Menu as well as the About box.

Back to top

Creating a Finder alias

Date Written: 6/14/91

Last reviewed: 6/14/93

How can I get my program to create a Finder alias?

Finder aliases are one aspect of the Macintosh human interface considered "reserved for users." The format is intentionally undefined because it is subject to change, and because alias files should be neither created nor altered by applications. The Finder is the user's domain, and aliases are a user convenience. If you are inclined to create an alias file, rethink your application design. Would clear instructions to users on how to make the aliases be adequate? Are the files your application needs too scattered?

If some demon still drives you to make alias files, the safest way to do it is by issuing Apple events to the Finder. The particular Finder event for making an alias is 'FNDR' 'sali'; it is documented in the Apple Event registry. Since this Finder event does not return either the name of or an alias to the new alias file, nor is there a Finder event for identifying the currently selected icons, moving the alias file elsewhere will be problematic.

The unsafe way to make an alias file is to create the file yourself. The format of alias files is undocumented; there is no guarantee that any alias files created by your application will always work. At present, you can construct an alias to a document by getting a handle to an alias with a NewAlias call, creating a resource file with the same creator and file type as the original file, adding the alias as a resource of type 'alis' and ID 0, and setting bit 15 of the file's Finder flags. Aliases to applications have the file type 'adrp'; folder, volume, and system file aliases use other special file types. Finally, alias files should have the same custom icons as their targets.

Once again, DTS urges that you not create alias files from within an application.

Back to top

Macintosh Finder extensions aren't supported

Date Written: 8/15/91

Last reviewed: 6/14/93

Please tell me how to write a Macintosh Finder extension.

Sorry, but Finder extensions are not supported. They are not documented, and facilities for them have not been adequately tested. It is doubtful that there is enough free space in the Finder to reliably add any extensions which are not a standard part of the system.

This situation may change in the future, but for now, DTS has nothing to offer to help you in trying to write your own Finder Extension.

Back to top

Macintosh Finder's 'fmnu' menu resource TMPL

Date Written: 11/27/91

Last reviewed: 6/14/93

A variety of homebrew TMPLs for the Finder's 'fmnu' menu resources have been "thrown over the transom" on AppleLink and other bulletin boards, but I don't recall anything official. Has Apple publicly documented this Finder resource?

Apple doesn't have an official TMPL for the Finder's 'fmnu' menu resources. It hasn't been publicly documented, because (to some extent) it's private to the Finder.

The Finder team agreed that there'd be no harm in releasing the Rez template they use, because users might want to mess with command keys, menu titles, etc, for their own use. However, they declined to release the definitions of the flag bits (marked below with three asterii); these should be left alone (they have to do with how the Finder decides to enable items and certain actions to be generically performed when an item is chosen). So, here's the template, with the caveat that it could change anytime:

type 'fmnu'
    {
    integer; /* flags *** */
    integer = $$CountOf(ItemArray);    /* number of items */
    array ItemArray
        {
        longint;                        /* command id */
        integer;                        /* item flags *** */
        string[1];                        /* key equivalent */
        align word;
        pstring;                        /* menu title */
        align word;
        };

Back to top

FindFolder and saving application preferences

Date Written: 2/28/92

Last reviewed: 8/1/92

In System 7, I want to place my user's preferences file in the Preferences folder in the System Folder, but I can't seem to get the Preferences folder's directory ID and other information so that my file will appear there! Also, how do I get to that folder if the user changes the names of the System Folder and Preferences folder? And once the user's preferences file is there, am I assuming correctly that the best way to find it again is to make an alias record to track the file ID?

System 7 introduced the routine FindFolder for locating the Preferences folder. Just make this call:

err := FindFolder (kOnSystemDisk, kPreferencesFolderType,

If FindFolder returns noErr, prefVRefNum and prefDirID will contain the vRefNum and dirID of the Preferences folder, which can be used later with HCreateResFile, HOpenResFile, PBHGetFInfo, and other File Manager calls to locate your preferences file. If a Preferences folder doesn't already exist, the kCreateFolder parameter instructs FindFolder to make one and return the vRefNum and dirID of the new folder.

FindFolder is documented in Chapter 9 of Inside Macintosh Volume VI, under "The System Folder and Its Related Directories." Although FindFolder is implemented only in System 7, if you're using MPW 3.2 (or the current THINK compilers) glue is automatically included in your compiled code, making it safe to call FindFolder in System 6. The glue checks whether FindFolder is available and, if it isn't, returns the System Folder's vRefNum and dirID for the kPreferencesFolderType selector. Use the System Folder values as the location for the preferences file in System 6.

If you're not using a development system that provides the FindFolder glue, your code should check the FindFolder Gestalt selector gestaltFindFolderAttr to see if FindFolder is available. If FindFolder is available, call it. FindFolder is defined as:

FUNCTION FindFolder (vRefNum: INTEGER; folderType: OSType;
    createFolder: BOOLEAN; VAR foundVRefNum: INTEGER;
    VAR foundDirID: LONGINT): OSErr;

If FindFolder isn't available, call SysEnvirons to find the System Folder's working directory reference number, call PBGetWDInfo or GetWDInfo to convert that number to a true vRefNum and dirID, and use those System Folder numbers for the location of the preferences file. Example code for this is in the Q&A stack, under Operating System:File System:Code for identifying vRefNum and dirID of Macintosh System Folder.

To locate the Preferences folder, follow the steps described above rather than trying to keep an alias of the Preferences folder or of the preferences file. However, if there are any other files in the System Folder that the application depends on (such as dictionaries) those should be tracked with aliases, stored as 'alis' resources in the preferences file. See Chapter 27 of Inside Macintosh Volume VI for information on using aliases.

Back to top

System 7.0 and color volume icons

Date Written: 3/4/91

Last reviewed: 6/14/93

Now that Macintosh Finder icons can be in color, is it possible to have color volume icons as well, and, if so, would you share the specifics?

Unfortunately, there's no way for the driver to provide the default icon in color--that is, there are no calls newer than those described in the Macintosh Technical Note "Finders and Foreign Drives."

The System 7.0 Finder can display a custom color icon for a volume, though. The user can paste a new color icon over the old one in the volume's Get Info box. (Click the icon in the Get Info box to select it, then Paste.)

Back to top

Reason for Finder "trash can't be emptied" alert

Date Written: 5/1/91

Last reviewed: 6/14/93

Why does the Macintosh Finder sometimes display the alert "The trash could not be emptied (a file was busy or a folder was not empty)" when the trash contains only an emptied folder?

This is the behavior that you get from the Finder when another application is running (presumably the one that owns the documents that were trashed) that has the folder open as a working directory. Unfortunately, some applications that open working directories aren't as careful as they should be about closing them, and the result is that the working directory doesn't go away until the application has quit. Once it does go away, however, the folder can be trashed with impunity.

Back to top

Saving as stationery for both Systems 6.0.x and 7.0

Date Written: 4/22/91

Last reviewed: 6/14/93

How should my application implement saving as stationery to be compatible with System 6.0.x as well as System 7.0?

When the user saves a document as stationery, your application should write it out with the appropriate stationery file type so both System 6.0.x and System 7.0 Finder vesions will display the file's icon correctly. Also, set the file's isStationery bit, which you'll use to identify the file when the user opens it, under either system version. Of course, along with the regular document's file type, you'll need to register the stationery file type with DTS.

Back to top

Old Finder information returned by PBGetCatInfo

Date Written: 12/18/91

Last reviewed: 6/14/93

I'm having trouble with PBGetCatInfo returning old data to my application. For example, if I change a file label using the Finder Label menu and then run my program, which calls PBGetCatInfo, the fdFlags field in the FInfo record returned doesn't reflect the change. I've tried calling PBFlushVol before I do this; the file isn't open, so there's no way to call PBFlushFile. However, restarting the Macintosh or changing the file's name causes PBGetCatInfo to work correctly. What's going on and how do I get around it?

The Finder caches much of the "Finder information," including things like the color coding information users can set with the Finder Label menu and the view position of objects in folder windows. Changes to the Finder information are cached until the folder that contains the objects that were changed is closed (which happens at system restart or shutdown time) or until some noncached change is made to the object (for example, the file is renamed). The Finder caches what it considers Finder-specific information to cut down on the number of disk accesses it must make. (For example, rearranging the object view in a window would be very slow on floppy disks if the Finder wrote to the disk every time the user drags a group of objects around.) Since in most cases no other applications should care about the state of the Finder information, this normally doesn't cause problems. There's no workaround for this behavior in the current implementation of the Finder.

Back to top

Quitting System 7 Finder

Date Written: 4/17/92

Last reviewed: 6/14/93

I've been thinking of shutting down the System 7 Finder. Is this a cool thing to do in my application?

We normally recommend that you don't quit the System 7 Finder application. Nevertheless, there may be a few good reasons to shut down the Finder. For example, the Installer (the only application Apple ships with a good reason to do so) sometimes needs to shut down the Finder and all other applications to make sure system resources aren't being used while they're being updated by the Installer.

If you find yourself in a situation where you need to shut down the Finder, you should know about a few things:

• Before you shut down the System 7 Finder, use the Process Manager to see if the File Sharing Extension is running. If so, you should shut it down before shutting down the Finder. The File Sharing Extension shouldn't be running without the Finder because the Finder is the only user interface the File Sharing Extension has. You shouldn't take away the user interface to file sharing.

There's another good reason to shut down the File Sharing Extension before the Finder. The Network Extension (not the Network control panel) handles all the user interface transactions among the Finder, the File Sharing Monitor control panel, the Sharing Setup control panel, the Users & Groups control panel, and the File Sharing Extension (the file server). The Network Extension opens another file, the Users & Groups Data File, so that it can manipulate users and groups. When you shut down the Finder (with a kAEQuitApplication Apple event), the Network Extension and its connection to the Users & Groups Data File are also closed (almost). Because of a minor bug in the system, the File Manager thinks that the file is closed and that the FCB used by that access path is free for reuse; however, the File Sharing Extension thinks the access path to the Users & Groups Data File from the Network Extension is still open. When the File Manager attempts to reuse that FCB to open another file later, the file is opened, but because the File Sharing Extension thinks that FCB is still in use by the Network Extension, it won't allow access to the file and it returns opWrErr (-49) to the Open call. At this point, the file that someone was attempting to open can't be accessed or closed.

• If the Finder is shut down and then eventually relaunched, there may be some fragmentation of the MultiFinder heap. This can occur because the Finder is the first application to be started, so it's always first in the MultiFinder heap. When you shut it down, that memory becomes available and other processes might occupy that space. When the Finder is restarted, if it can't get into its original space in the MultiFinder heap, it will get loaded somewhere else and probably won't be shut down again.
• In System 7, the Finder is responsible for filling the Apple menu with the items in the Apple Menu Items folder. When the Finder is gone, so are the Apple menu items, including things that are important to most users (like control panels).
• If the user has selected background printing with a LaserWriter or StyleWriter, nothing will print while the Finder is gone. That's because the Finder is responsible for monitoring the PrintMonitor Documents folder and launching the PrintMonitor application when necessary.

Back to top

Special Macintosh alias file types

Date Written: 3/14/91

Last reviewed: 6/22/93

Why does the alias of a font suitcase created in System 7.0 have a type of 'drop' instead of 'FFIL'? Should applications that open 'FFIL' files also try to open 'drop' files?

While it is true that an alias file generally has the same type and creator as the file it points to, certain special Finder objects are given their own type, such as aliases to server volumes. An alias file of type 'drop' is an alias to a container object--that is, one that can contain other files like fonts. A list of special alias types is in the Finder Interface chapter of Inside Macintosh Volume VI and is defined in Finder.h. For information about the alias type for the Fonts folder, see the Finder Q&A "System 7.1 Fonts folder selector is 'font'."

You asked why the Finder needs to create this special type. The user is allowed to drag objects around the desktop, and if an object is dragged over something it can be dropped on or into, such as a folder, that object is immediately highlighted so the user knows this is a cool thing to do. Since the actual object an alias file points to may not even be currently accessible--for example, if it's on a server volume--the Finder can't resolve it immediately to know if it's cool to highlight the object, so alias files of type 'drop' are a catchall type that tells the Finder dropping is cool.

You should not assume an alias file of this type always points to a font file. It can also point to a desk accessory, for example. If you want to handle this type properly in a standard file dialog, you need to filter on type 'drop', then have a filter proc which attempts to resolve the alias file. See the Macintosh Technical Note "Resolving Alias Files Quietly" for code to resolve the alias file without raising a dialog.

Alternatively, you can allow the user to select the file for opening and then if it doesn't resolve to the correct type, inform the user via a dialog that the file isn't of the appropriate type.

Back to top

Macintosh System 6.0.x Finder rules for emptying trash

Date Written: 1/21/91

Last reviewed: 6/14/93

When does the Macintosh 6.0.x Finder empty the trash?

According to the Finder source code, here are the conditions under which the trash will be emptied:

• Whenever a copy is done, both the source and destination disk's trash will be emptied.
• Whenever a disk goes off line.
• Whenever a disk is ejected.
• Whenever a disk is formatted, the trash will be emptied before the formatting begins.
• Whenever the user selects empty trash from the "Special" menu.
• Whenever an application is launched.
• Whenever the system is shut down.

(I determined this by searching the source for all occurrences of the trap _Delete. Then I looked at each of the routines to see if they pertained to trash management. If they did, I searched the source for all occurrences of those routines, looked at each of those and figured out what the enclosing routine did. Since all this was done by examination, it is possible that I missed something.)

Back to top

What do all the bits in System 6 Finder's 'LAYO' resource mean?

Date Written: 5/3/89

Last reviewed: 6/14/93

What do all the bits in the System 6 Finder's 'LAYO' resource mean?

The following is probably the only documentation to be found on the 'LAYO' resource. It describes only the settings, not their values. You can use ResEdit to look at and change the values, but you do so at your own risk.

Font ID and size: These change the font and size of most text displayed by the Finder, including the icon titles, the window top margin text, all the text in the text views, and the printed text generated by "Print Catalog." If, after changing font ID or size, you later change the System fonts or use the Finder with a different System file, the font you specified may be missing. In that case the default font will be used. If the size you specify is not available, a scaled size will be used.

Window rect: This is the rectangle that controls the position and size of new windows created by the Finder. Windows of new folders are given the same view as the "parent" window, has regardless of the window rect.

Tab stops 1-7 and column justification: You can adjust the column spacing used to display in the text views. The Finder truncates any text that is too wide for the column, so make sure the size, date, time and other columns are wide enough. You cannot change the ordering of the columns or eliminate any of them. Each column can be left or right justified.

Icon spacing options: You can adjust the grid spacing by dragging the light gray icon, and the grid offset by dragging the dark gray icon. The grid offset vertically staggers the icons, allowing you to space the icons a bit closer together but still read the document titles. The grid you specify will be used when you do a "clean up" or grid drag, or when a new icon is created in a "by icon" format window.

Text view date: The format of the date can be set to short (12/25/87), medium (Thu Dec 25, 1987) or long (Thursday, December 25, 1987).

Use zoom rects: This is normally set TRUE, which means that the usual zooming effect takes place when the Finder opens a window or an application. If you set this to FALSE, the Finder does not use the zooming effect.

Skip trash warnings: DISABLING THIS OPTION IS POTENTIALLY DANGEROUS. If you set this TRUE, the Finder will skip the usual warning that is given whenever you throw an application or system file into the trash.

Always grid drags: This option is normally not set, which means you can position icons freely on the desktop. If you set this TRUE, whenever you drag an icon, the icon will snap into position on the grid automatically without having to do a "clean up."

Sort style: This option adjusts the style of the column heading by which the view is sorted. See the previous section on "text views" for more information. The column in which entries in the text view are sorted ("name in view" by name, "kind in view" by kind) is displayed according to the setting of the sort style.

Watch thresh: This allows you to adjust length of time before the Finder will display a wristwatch cursor with animated hands during such lengthy operations as file copying. Older Finders don't use the watch thresh option, so it is disabled and cannot be selected. The time is expressed in 60ths of a second. If you set length of time too short, the cursor will jitter and change shape too often.

Use phys icon: This forces the system to display the floppy disk icon instead of an icon with an arrow pointing to a disk drive.

Title click: This option is normally set FALSE. If it is set TRUE, a feature in the Finder is enabled, allowing you to double-click the title bar of a window so that window's "parent window" opens or comes to the front if already open. The "parent window" is the one that contains the folder the original window represents.

Copy inherit and new folder inherit: These options are for AppleShare folder privileges. They only affect folders created on an AppleShare server.

Color style: Normally, folders and file icons are displayed with a color outline. Color style causes these icons to be filled in with color.

Max # of windows: This allows you to set the maximum number of windows the Finder can open at one time. Increasing the number of windows causes the Finder to need more memory. Under MultiFinder, you may have to increase the memory allocation for the Finder.

Back to top

Downloadables