There are some minor and major changes to the Finder’s dictionary:
Class Application now includes a new element, View Options Window, and there is a new View Options Window class to go with it.
Class Application now also includes a new Execution State property which may assume any of these values: starting up, running, rebuilding, desktop, copying, restarting, and quitting.
There is a new optional parameter to the Put Away command, asking, which specifies whether or not to present a dialog to confirm putting this item away.
The Scriptable Finder 9.1
These new AppleScript-related features in Finder 9.1 are described in the Mac OS 9.1 Technote:
The ‘put away’ [command] now has an optional ‘without asking’ parameter… The effect of the optional ‘without asking’ parameter is to inhibit any alerts that may appear during processing of the command such as ‘This disk will re-appear when you next start the machine.’
It is now possible for scripts to determine if they are being called as part of the shutdown sequence or the restart sequence. To discover the current execution state scripts can use the Finder’s execution state property. The property includes these states: restarting, starting up, running, rebuilding desktop, copying and quitting. This feature implements a couple of long-requested improvements that many scripters will welcome. John Baxter spoke for all of us when he said on the MACSCRPT list on January 19, 2001, A script running from the Shutdown Items folder can now (one might say finally…one will say THANKS) tell whether Finder is trying to shut down or restart the machine.
One other, more minor, change in the Finder’s dictionary is described above in the Dictionary Changes section.
Scripters who work with the Finder should note that, in Mac OS 9.1, changing the name of a file or folder will change the modification date of the enclosing folder. This is a departure from previous behavior. It should make it easier for a script to identify folders whose contents have changed. 2/11/01
Several long-standing bugs in the scriptable Finder, including some remaining from at least Mac OS 8.1, have finally been fixed in Mac OS 9.1. I listed and ranked what I regarded as the eleven most important Finder bugs in the note on AppleScript 1.3.7 in Mac OS 8.6. One of these, the duplicate in place bug (no. 2 in importance, by my ranking) was fixed in Mac OS 9. Three more of these are fixed in Mac OS 9.1 (nos. 1, 6, and 9 in importance, by my ranking). All-in-all, Mac OS 9.1 is an excellent system release for Finder scripting. (Of course, scripts that may run on earlier systems must still apply workarounds to cope with these fixed bugs, as well as the old bugs that have not been fixed.)
The following AppleScript-related bug fixes in Finder 9.1 are mentioned in the Mac OS 9.1 Technote:
The Finder will now properly activate windows that it opened in response to Apple events from other applications while running as a background application when the Finder is switched to the front most application.
Items found in the temporary items folder at system startup are, once again, moved to the rescued items folder in the trash. This cures a bug in Mac OS 9 that had led to the creation of many AppleScripts and other utilities designed to work around the problem.
A problem, that has existed since Mac OS 8.5, where the ‘titled’ property of a Finder window was compiled into scripts as the resizable property has been corrected.
In previous versions of the Finder, asking for a list of creator types of all the active processes would return a list of object references instead of a list of four letter strings. This problem appears in Mac OS 8 through Mac OS 9.0.4 and was not present in Mac OS 7.x… This command has been updated so it will always return a list of four character strings…
Scripts … attempting to retrieve the names of all ejectable disks no longer fail. In the past, such scripts would abort with an error such as ‘Finder got an error: Can’t get name of every disk of desktop whose ejectable = true.’
Since Mac OS 8.5, scripts using modification and creation date properties associated with files did not work. This problem appears in Mac OS 8 through Mac OS 9.0.4 and was not present in Mac OS 7.x. This problem has been corrected… This is the longstanding bug where comparisons of some creation dates and modification dates produced erroneous results. It also affected comparisons of other numeric values (AppleScript dates are numbers). Now, all of these comparisons appear to work, allowing scripters once again to use the very fast Finder filter reference form (whose clause) to create lists of qualifying files and other Finder items. For example, every item of folder Test folder where size of it < 5000.0.
There is one fix to the Finder which I had hoped, on first reading, would resolve a longstanding Finder AppleScript bug. The Finder now supports redirection (by way of the Folder Manager APIs) of the Desktop Folder to volumes other than the startup volume. The Finder now relies entirely on the Folder Manager to determine the location of the Desktop Folder and makes no assumptions about its actual location. Unfortunately, using AppleScript to obtain the path to an item that was dragged to the desktop from a non-startup disk still reports that it resides on the startup disk.
Some have reported that, although the long-standing bug in which the Finder’s entire contents property fails on large containers still exists, it now generates an error when it fails. The error message is reportedly garbled, but the error number is reportedly -108 (out of memory). Others report a different error number. Still others assert that this behavior has existed through several revisions of the Finder, and that the generation of a testable error remains hit or miss. In the absence of confirmation from Apple, the prudent course is to assume that the Finder’s behavior is unchanged and to use the entire contents property as carefully as you can, if at all. Most report that it works reliably on relatively small containers, but not everybody accepts the about 250 items upper bound of the safe zone reported by some.