Mac OS 8.0, introduced in July 1997, has brought us the first upgrade to AppleScript since the release of AppleScript 1.1 in December 1993, 3-1/2 short years ago. AppleScript 1.1.2 includes an unexpectedly large number of changes, including new features, modifications to existing features and long-awaited bug fixes. Many of the new and altered features reflect modifications to the Mac OS 8 Finder, but there are others to contend with, as well. A number will break existing scripts; backwards compatibility is a serious issue. In addition, new bugs have been introduced which require workarounds (including new bugs in the AppleScript support in Finder 8.0 and Finder 8.1). Serious scripters will want to review all of their existing scripts to ensure that they run properly under Mac OS 8 and take advantage of the new capabilities of AppleScript 1.1.2.
Mac OS 8.1, introduced in January 1998, still includes AppleScript 1.1.2. None of the AppleScript components has been upgraded. However, Finder 8.1 is new, and many (but not all) of the bugs in Finder 8.0’s AppleScript support are now fixed in Finder 8.1, and some new bugs are introduced.
While much of the information here is simply a convenient summary in one place of information from scattered official sources, it is interlaced with my own comments, explanations, suggestions and examples. In addition, I provide here an all-new and exhaustive enumeration of changes in the Finder 8 Apple event dictionary.
Products relating to AppleScript are quickly being upgraded or released to work with the new and changed features of Mac OS 8. Upgraded and new products taking advantage of Mac OS 8 are listed here.
Drew Thaler 's CLImax 1.5d2 is available for public testing. This remarkable application now runs under Mac OS 8. It provides an interface for running AppleScript commands from a command-line window. [It is no longer available. 9]
Michael Schuerig’s CMScript 1.1 is a Mac OS 8 Contextual Menu Manager plug-in for running AppleScripts from contextual menus. The final version was released January 4, 1998.
WestCode Software has released OneClick 1.0.3, an upgrade to this advanced launcher palette and button bar utilitiy for Mac OS 8 compatibility. The upgrade does not yet resolve the inability of certain OneClick scripting commands to return values from Finder 8.0 when they are issued while the Finder is frontmost.
OSA Menu 1.1, Leonard Rosenthol’s utility for running compiled scripts from a menu in the menubar, works with Mac OS 8 and the threaded Apple event implementation found in Finder 8.0. The final version was released December 11, 1998.
PreFab Software’s web site contains information about Mac OS 8 issues affecting PreFab Player, including a workaround if popup menus remain open after a single click. PreFab Player is an industry-standard utility for scripting otherwise non-scriptable applications.
A Script Debugger 1.0.5 upgrader is available to bring this AppleScript Editor into Mac OS 8 conformity.
The changes wrought by this new version are documented in a variety of sources, summarized here:
The Scripting Mac OS 8 overview
Apple’s official AppleScript web site provides a long and detailed description of AppleScript’s modifications. Several sample scripts exercising AppleScript’s new features are included, along with a list of new bugs and workarounds. 10/10/99
Macintosh Technical Note 1102 for Mac OS 8.0
Technical Note 1102 Mac OS 8 has been posted to the Apple Developer World site. Discussion of several AppleScript issues is included.
Macintosh Technical Note 1121 for Mac OS 8.1
Technical Note 1121 adds some new AppleScript information for Mac OS 8.1.
The Mac OS 8 read me files
Several of the read me documents and other items that are installed with Mac OS 8 and its components include references to AppleScript.
The most broadly informative files are the Using AppleScript SimpleText documents that are installed with AppleScript 1.1.2. Part 1 outlines the changes and bug fixes in AppleScript. Part 2 is a short instruction manual for using Apple’s Script Editor to write scripts.
A very brief introduction to AppleScript appears in the new Mac OS Info Center, a set of html files that is installed with Mac OS 8. From the Info Center’s Main Menu, click on Discovering What You Can Do, then What Can I Do With the Mac OS?
In the Extensions Manager, click on the AppleScript 1.1.2 extension to see this description of AppleScript:
Contains the software needed for Macintosh Scripting, including the AppleScript language. Scripting lets you record and automate tasks on your Mac OS computer. It is required by all applications and system software.
(The AppleScriptLib 1.2.2 extension, although it bears the Mac OS 8.0 package designation, contains no description for the Extensions Manager.)
The About Mac OS 8 SimpleText document briefly mentions three specific issues relating to AppleScript that are more fully described elsewhere.
A specific document is the Apple Location Manager Read Me for Location Manager 1.0.2, a PowerBook utility for users who need to change printers, servers, network access parameters and other settings when they travel. The document is little changed from the original release of Location Manager. It contains the source code for an AppleScript applet that can be placed in the Startup Items folder to cause the computer to open to a specific location set at startup. It also contains instructions for assigning applications and other Finder items to specific locations as Auto-Open Items, which will be opened automatically whenever a new location is activated (whether at startup or at any other time). Although the read me document does not point this out, an AppleScript applet can be designated as an Auto-Open Item, giving you great power to control your configuration automatically when changing locations.
Apple’s User Interface Guidelines supplement for Mac OS 8
The Mac OS 8 supplement has a topic on scripting control panels. Here is the Scripting topic in its entirety: Control panels should be scriptable using AppleScript.
The information from all of these sources and others is combined and summarized below, to give you a complete picture in one place. Information from other sources will be specifically attributed to them as it accumulates.
AppleScript 1.1.2 and Mac OS 8 are not completely backwards compatible. If any of your scripts makes use of the new scripting features, such as pop-up windows, be sure to include code to check for the presence of Mac OS 8 if they may be distributed for use on machines that are running older versions of system software. Two sample script snippets that abort script execution on older versions of the Mac OS are included in the Checking for Mac OS 8 section of Apple’s Scripting Mac OS 8 overview.
The other side of the coin is that some scripts compiled in System 7 will break if run under Mac OS 8, because certain features have been moved in Mac OS 8, or eliminated in favor of others. The principal examples are file sharing, dictionaries for which have been moved from the Finder Scripting Extension to the new control panel applications, and some aspects of finder views, which can now be set separately for individual windows but no longer globally. If you are not going to rewrite those older scripts for Mac OS 8, you should consider adding a check for the presence of System 7 in case they fall into the hands of Mac OS 8 users.
The Scripting Mac OS 8 overview also contains a Compatibility or Just Friends? section describing techniques for writing scripts that will run properly both under new and old versions. Most valid scripts compiled under System 7 should run without change under Mac OS 8, and most valid scripts compiled under Mac OS 8 that do not make use of new features should run without change under System 7. There are certain situations where scripts compiled under one version of the Mac OS must be modified slightly in order to be run under the other version, even if they do not make use of new features. These situations are described below in connection with the new obsolete properties of the Mac OS 8 Finder.
NEW FINDER SCRIPTING FEATURES Finder Scripting Extension Removed
The Finder Scripting Extension is finally gone. Most of its code has been incorporated into the Finder itself. Benefits of this change include the fact that new scripters will no longer encounter the puzzle of one Apple events dictionary (long obsolete) in the Finder itself and another (now also obsolete) in the Finder Scripting Extension. Another benefit, for developers of script editing applications, is that script editors will no longer have to look in a separate file for the Finder’s dictionary.
Threaded Apple Events
In the Mac OS 8 Finder, Apple events that are initiated within the Finder process via system patches are handled in separate threads. Upon receipt of such an Apple event, the Finder first suspends the event, creates a Thread Manager task where the event will be handled, and schedules the task for execution. Once the thread has completed execution and is ready to return a value, the Finder resumes the Apple event.
What this means is that threading creates problems for certain software products that cause the system to send Apple events to the Finder while it is frontmost, because AppleScript thinks they have timed out. For example, OSA Menu has already been upgraded to version 1.1 to deal with this problem. Another example is OneClick; even the 1.0.3 upgrade for Mac OS 8 compatibility is not yet able to return values from Finder 8.0 when certain commands are issued while the Finder is frontmost. Here is Apple’s technical explanation:
Products patching the system and sending Apple Events to the Finder with the send mode kSendToSelf while the Finder is the current process may require revision. In this case, AESend will return the error errAEEventTimeout, which requires special handling. The caller should handle this error by periodically attempting to extract data from the reply event. Also, the caller should be sure to yield time to the System so the Finder can run and process the event. When the Finder completes processing of the event, the reply will contain the requested data.
The fact that the Finder is threaded also has significance for script authors. An AppleScript script can now send multiple commands to the Finder in rapid succession without waiting for a return value, and they will be executed in parallel. For example, multiple file copies can be initiated successively within an ignoring application responses block, such that all will run simultaneously. Turn to Parallel Processing for examples.
Obsolete Finder Properties
The following properties of the Mac OS 8 Finder, although using the same English locution as the System 7 Finder Scripting Extension, are compiled to new OSA codes:
modification date
creation date
folder (the property, not the item)
file type
locked (a file property)
The purpose of the new codes is to eliminate conflicts with the Info For command in the File Commands scripting addition.
In order to run a script under System 7 that is to be compiled under Mac OS 8 using any of these properties, the word obsolete must be appended (as in file type obsolete). AppleScript 1.1.2 will then compile the property into the old System 7 code instead of the new Mac OS 8 code. A script that was compiled under System 7 without using the word obsolete will, if examined under Mac OS 8, appear with the word obsolete automatically appended; contrariwise, if compiled under Mac OS 8 with the word obsolete, it will appear in System 7 without the word obsolete. In either case the compiled script contains the same code but is rendered differently in English depending on which system is running when it is examined. Any such script may be compiled under either version of the Mac OS (with obsolete under MacOS 8 and without obsolete under System 7), and it will run properly under the other version without modification, whether or not recompiled on the new host.
If a script is instead compiled under Mac OS 8 using any of these properties without the word obsolete, AppleScript 1.1.2 will compile it into the new Mac OS 8 code, and it will generate an error when run under System 7 without recompilation. Although it may therefore be desirable to use these obsolete codes for a time, while System 7 is still in use, they will eventually be removed from AppleScript. Your scripts written with obsolete will eventually fail to compile, and scripts already compiled will fail to run, under future versions of the Mac OS once this backward compatibility feature is removed. It is not too soon to begin upgrading your users to Mac OS 8 now! Once all of your users are converted to Mac OS 8, you can recompile your old scripts using these properties without obsolete and be ready for the future.
There was an amusing exchange on the MacScripting mailing list in late July 1997 about the origin of the obsolete solution. Jon Pugh started it with this:
This is all my fault in some way, but I can place blame elsewhere pretty easily too. Since I was laid off in 93 from the position of AE Registrar, there was no one to review the scriptable Finder’s aete, and it shipped with several terminology conflicts, notably with the info for osax. Later, after I was rehired by Apple, I filed a bug against the Finder. It was dealt with in this manner. I, however, was once again laid off in the 97 purge and didn’t get a chance to play with the prerelease version to make sure that they fixed things correctly. They apparently did not and no one else really tested things either.
Cal Simone then stepped in, saying, as I have in the past, I’ve taken some of the blame for this also. He proceeded to recount this history:
They asked me to review the Scriptable Finder’s terminology, but it was so massive (27 pages printed) that I needed to devote an entire weekend. After about a month, I finally reserved an entire weeked, and guess what – on the Friday afternoon going into that weekend, the word came down, Congratulations, the Scriptable Finder is frozen (even though it was more than three months before it shipped). I cried, Nooooooo! But it didn’t matter, no response.
So the Finder shipped as you know it with the System 7.5 release…
Well, I tried like the dickens to get it before System 8 went beta, but I wasn’t able to get anyone to send me the Pieces of Eight (those that are scriptable) until very late in the cycle.
Finder Views
The new View Options command of the Mac OS 8 Finder allows users to set certain characteristics of finder windows, such as icon size and visible columns (in list views), differently in each window. Older Finders only allowed these to be set globally. Because of this change, scripts running under Mac OS 8 can only set the view attributes of a single window.
John Blackburne has posted his SetViewOptions droplet to allow users to set the Finder’s view options for all enclosed folders at once under Mac OS 8. A script from Apple with similar functionality appears in the Scripting Mac OS 8 overview. Yet another recent entrant in this rapidly growing new software category is OS 8 Views Setter 2.0. Other solutions have also become available.
Network Commands
Network commands relating to file sharing and networks are no longer part of the Finder’s AppleScript repertoire but have been moved to the appropriate control panel applications. (These are of file type ‘APPC’.) This includes creation and manipulation of network users and groups and retrieval of information about connected users and file sharing activity. These changes break old scripts. For compatibility with Mac OS 8, in most cases, all that is required to upgrade them is to tell either the File Sharing control panel or the Users & Groups control panel instead of the Finder to perform the action. The worst compatibility problem is avoided, however, by continuing to allow the Finder to turn file sharing on and off.
The new File Sharing control panel application replaces both of the old Sharing Setup and File Sharing Monitor control panels. It provides scripting support for starting and stopping shared services, querying server status, and manipulating connected users and shared items. The new Users & Groups control panel application provides facilities for the specification and configuration of user names and passwords for people who are able to establish network connections with the computer. It is scriptable and recordable.
Additional AppleScript support for file sharing is provided by the FileSharing Commands scripting addition, which duplicates the most commonly used scripting support found in both the File Sharing control panel and the Users & Groups control panel. This scripting addition is provided so that scripts are not required to launch the control panels to access File Sharing services. For security reasons, many of the commands found in the FileSharing Commands scripting addition cannot be used remotely (via scripts run on a different machines across a network). To access the File Sharing and Users & Groups control panels on a remote computer, you must remove the FileSharing Commands scripting addition from the Scripting Additions folder on the remote computer and enable program linking in the File Sharing and Users & Groups control panels.
Application Processes
Each of the Mac OS 8 Finder properties application processes, accessory processes and processes returns a list. Application processes has always returned, and continues to return, a list of type typeProcessSerialNumber ('psn '), such as ‘{application Script Editor, application Stickies}’. However, first application process will now return ‘process Script Editor’, which is a different data type (‘prcs’) than ‘application Script Editor’ as returned by System 7. (Also, see the bug list below for a bug when using the filter reference form with first application process.) According to the Mac OS 8 Technical Note, [d]evelopers wishing to obtain the same data type for both Finder 7 and Finder 8 should use the query ‘first application process as <>’ (note the space after n) in their scripts, which will return the value 'application Script Editor ’ with both Finders.
No clear explanation is given regarding the purpose of this change. On its face, it seems to present an inconsistency, since, according to the documentation, a request for a list of processes will return a list of items of one type (type 'psn '), while a request for the first item in the very same list will return an item of another type (type ‘prcs’). To compound the confusion, a request for the class of application processes and of first application process will return the identical answer, a list of application process in the first instance, and a list of application process in the second. Perhaps the answer is that there was always an inconsistency in this area. At least the pattern has a certain consistency, as shown in this snippet:
tell application "Finder"
-- Stickies is an application;Key Caps is an old-style desk accessory
processes
-- {application Stickies, application Key Caps}
class of processes
-- {application process, accessory process}
first process
-- process Stickies of application Finder
class of first process
-- application process
process "Stickies"
-- process Stickies of application Finder
class of process "Stickies"
-- application process
process "Key Caps"
-- process Key Caps of application Finder
class of process "Key Caps"
-- accessory process
application processes
-- {application Stickies}
class of application processes
-- {application process}
first application process
-- process Stickies of application Finder
class of first application process
-- application process
application process "Stickies"
-- process Stickies of application Finder
class of application process "Stickies"
-- application process
application process "Key Caps"
-- error; it is an accessory process
-- 'Can't get application process Key Caps'
class of application process "Key Caps"
-- error; it is an accessory process
-- 'Can't get application process Key Caps'
end tell
Does this change have any consequences for script authors? Yes, at least one. The currently-favored double-tell technique for launching applications by variable no longer works under Mac OS 8. Basically, the favored double-tell technique under system 7 involves opening an application file by its id in order to avoid the problems caused when users change their applications’ names, then telling the target application both by its name on the compiler’s machine and by a variable set to its first application process on the user’s machine (as in ‘set myApp to first application process whose creator type is quil’). This technique no longer works under Mac OS 8 because the first application process is now a process rather than an application, and a process does not understand application events. The workaround, as the documentation notes, is to add as <> (as in ‘set myApp to (first application process whose creator type is quil) as <>’.) Don’t forget the space following the n. For myself, I have always preferred to implement the double tell by finding the name of the application on the user’s disk and then telling it both by its name on my machine and by a variable set to its name on the user’s machine, and this change in Mac OS 8 leaves me feeling even stronger about this personal preference.
New Events Sent by the Finder The Reopen Application Apple Event
A long-known shortcoming of AppleScript applications (applets) has been the fact that you can’t run a stay-open AppleScript application that is already running (for example, by double-clicking its icon in the Finder, or selecting its icon and choosing the Open command in the Finder’s File menu). Doing this does not call the applet’s run handler; simply put, nothing happens. For example, a stay-open applet whose run handler acts on the current Finder selection works the first time the applet is run, but it does nothing if the user selects a second item and runs the applet by double-clicking on it again. This can be confusing to users, and it limits what the script writer can accomplish. The workaround has been to write non-stay-open applications, but it takes time for such an applet to quit and then open again the next time the user runs it.
The Mac OS 8 Finder solves this problem by implementing a new reopen application Apple event (‘rapp’), which is sent to any running application when a user attempts to open it by a double click (or by selecting the application and choosing the Open command or running it from the Apple menu). According to Apple, applications receiving this new event should be designed so that, if they do not have any windows open, they open a new untitled document just as they would when processing an open event. We will undoubtedly begin to see this behavior as applications are updated to take advantage of Mac OS 8.
Although it is not suggested in any of the documentation, it occurred to me that authors of stay-open AppleScript applications can now include in their scripts a handler to receive the new reopen event. When a user double-clicks such an applet and it is already running, the applet’s reopen handler will be called instead of its run handler. In the normal case, script authors will want to have the reopen event simply call the run handler – but the possibilities are endless. I suggest that all stay-open AppleScript applications written for the Mac OS 8 environment should include a reopen handler.
The technique for implementing the reopen event in a stay-open script application is identical to that used to create cgi scripts for web servers. Use the double-chevron notation that AppleScript provides for events and classes that aren’t found in an application’s dictionary. Here’s an example; compile and save it as a stay-open application, then double-click on it once and then again. The first time, it beeps once because the run handler was called; the second time, it beeps twice because the reopen handler was called and then a third time because the reopen handler called the run handler.
on run
beep 1
-- Hear only one beep the first time you run me
end run
on <<event aevtrapp>>
-- reopen
beep 2
run
-- Hear three beeps the second time you run me
end <<event aevtrapp>>
Try it; you’ll like it! For additional discussion, turn to Rerunning Applets. For a real world script that makes good use of the reopen event and demonstrates one possible user interface for it, examine Purge OSL.
Determining Screen Location Contents
A more difficult challenge for inventive scripters is presented by another new Mac OS 8 Finder Apple event, which allows clients to access an icon or window at a particular global screen coordinate. This event, like the reopen event, is not included in the finder’s Apple event dictionary, so some creative coding will be required – if it is possible at all. Here is what the Mac OS 8 Technical Note says about it:
To access this facility, ask the Finder for the desired type (icon or window) with formAbsolutePosition and keyData of typeAEList containing the horizontal and vertical global coordinates (as separate integer values). In cases where requests for typeWildCard (instead of a window or an item) are made, the Finder will provide an object specifier for an icon if there is one at the point, or a window (or the desktop).
We are warned that this event may be removed in future versions of the Finder.
ntercepting Documents
A third new Mac OS 8 Finder Apple event is ‘fopn’, which is sent by the Finder to an application whose document was double-clicked or otherwise opened by the user, before the Finder opens the document. It, too, is omitted from the Finder’s Apple events dictionary and may be removed from future versions of the Finder. This event allows an application to tell the Finder to cease processing the user’s open command and to override the Finder’s normal processing of the command. This event seems clearly to be intended for application developers only. Even if a way to trigger and intercept this event from a script could be devised, I see no purpose in doing so because AppleScript applications have no owned documents.
Dictionary Changes in Finder 8.0 and 8.1
Some changes to the Finder dictionary reflect new and changed functionality in the Mac OS 8 Finder. For the most part, these have been fully described in official Apple sources, including the read me files that are installed with Mac OS 8.0, Apple Technote 1102 for Mac OS 8.0 and Apple Technote 1121 for Mac OS 8.1, and the AppleScript overview posted on Apple’s official AppleScript site. Other changes, however, have not been mentioned in any source that I have seen. Note, for example, the new description property of the item class, and the new label class that permits scripting control of the color properties of finder labels.
Still other changes to the Finder 8.0 dictionary merely make it more accurately descriptive of functionality that was already present in the Finder Scripting Extension 1.1 and that has long been described in the Finder Guide. In particular, several classes that were formerly listed under the wrong suite with incorrect information are now moved to the right place in the dictionary with correct descriptions. The Finder 8.0 dictionary is therefore now a more useful quick reference for scripting the Finder.
The Finder Scripting Extension 1.1 stated that certain terminology, namely, the item parameter of several events, was provided for backwards compatibility with old event suite. Will be removed in future Finders. The Finder 8.0 dictionary does in fact remove this parameter from several events, as noted below.
The Finder 8.0 dictionary uses the term DEPRECATED to describe two subsets of terminology that are retained in the new Finder for backward compatibility with the Finder Scripting Extension 1.1 but that will be removed in future versions. One subset is described as being retained in Finder 8.0 for backwards compatibility with Finder Scripting Extension. DEPRECATED – not supported after Finder 8.0. Scripts can be written under Mac OS 8 to be run under System 7 using this subset of DEPRECATED terminologies; however, old scripts that use them must be rewritten now in order to run under Mac OS 8 because the corresponding functionality no longer exists in Finder 8.0. The other subset of DEPRECATED terminologies, each using the term obsolete, is described as : DEPRECATED - for use with scripts compiled before Finder 8.0. Will be removed in the next release. As explained elsewhere, scripts compiled with Finder Scripting Extension 1.1 will, when read with Finder 8.0, automatically append the word obsolete to these obsolete terminologies; and the word obsolete must be appended to scripts compiled with Finder 8.0 that are intended to be run with Finder Scripting Extension 1.1. While old scripts using these obsolete terminologies will still run under Mac OS 8, forward-looking script authors serving a Mac OS 8 market should open old scripts in Mac OS 8, remove the word obsolete, and recompile them, in order to increase the likelihood that they will run without change under the next version of the Finder.
All of the changes in the Finder 8.0 dictionary are described below, except that only the more interesting changes in the text of the descriptions of events, classes, elements and properties are mentioned.
Required Suite: print event:
-1.1 warned that the items optional parameter would be removed in future Finders, and it is gone in 8.0.
Standard Suite:
The order in which the classes are listed in the new Script Editor’s Dictionary window is different, but it is the same in another script editor. I assume this is of no significance; the names and number of the classes are the same. Note, however, that the application, file and window classes, which were duplicated with different elements and properties in the Standard Suite and the Finder Suite under 1.1, are now consolidated under the Standard Suite in 8.0.
duplicate event:
-1.1 warned that the items optional parameter would be removed in future Finders, and it is gone in 8.0.
-8.0 adds the routing suppressed parameter. If this parameter is set to true, the duplicate event will allow a script to place any of the Mac OS 8 special files (such as system extensions, control panels and scripting additions) at the root level of the System Folder, overriding the Finder 8.0 autorouting behavior (if there is any reason you might want to do so). My testing establishes that the duplicate event works correctly when used in this fashion, and also that duplicating any file, including special files, to other folders works as before. The default value of the routing suppressed parameter is false, implying that, if the parameter is omitted (or if it is explicitly set to false), then special files will be autorooted to their proper subfolders automatically if directed to the System Folder without specifying a subfolder. In fact, however, attempting to duplicate a special file to the System Folder under Finder 8.0 results in the user canceled error and nothing happens – whether the parameter is omitted or is included and set to false. Autorouting simply does not work under script control with the duplicate event in Finder 8.0. The workaround is to duplicate special files explicitly to the correct destination subfolder within the System Folder. This is fixed in Finder 8.1.
move event:
-8.0 adds the optional positioned at parameter, which accepts a list in local window coordinates of the desired positions of the destination items in icon view. You can tell the Finder where to position items by enclosing the desired local horizontal and vertical pixel coordinates of the upper left corner of the icon’s destination in double curly braces, like so: {{x, y}}; in other words, the coordinates must be passed as a list of lists even if you are moving only one item. The positioning instructions will be honored even if the destination window’s view options are set to Always snap to grid, but not if they are set to Keep arranged by. They are also honored if the window is set to list view, as you will see if you then switch to icon view. The icon will be superimposed on existing icons if any are in the way. The destination window need not be open.
If you are moving a single item, either of these techniques works:
tell application "Finder"
move file "A" to startup disk positioned at {{"1", "1"}}
end tell
tell application "Finder"
set destLoc to {{"1", "1"}}
move file "A" to startup disk positioned at destLoc
end tell
There appears to be a bug with the positioned at parameter in Finder 8.0, and it has not been fixed in Finder 8.1. Positioning a moved file at {{0, 0}} in another window places the icon outside the destination window’s scrollable content area 16 pixels to the left and 28 pixels above the specified position. It apparently treats the window’s origin, or {0, 0} point, as being somewhere beyond the upper left corner of its outside border, instead of at the upper left corner of the window’s content area, as it should. This occurs whether the window is open or closed, set to small or large icon view, and with or without Always snap to grid. This is inconsistent with the frame of reference used for the similarly-named position property of the item class, which treats the origin as being at the upper left corner of the scrollable content area of the window. The following script illustrates the problem; the file is positioned at {1, 1} using the move command, but the position property of the item class returns the value {-6, -20} in Finder 8.0 and a slightly different value in Finder 8.1.
tell application "Finder"
move file "A" to startup disk positioned at {{"1", "1"}}
get position of item "A" of front window -- {-6, -20}
end tell
The workaround is simple: just add the difference to the values you want for the position property of the item class. But the inconsistency is inconvenient and should be fixed.
The positioned at parameter was not added to the duplicate event, so making a copy of an item at a new location requires two steps, duplicate and move.
-8.0 adds the routing suppressed parameter, which works like that added to the duplicate event including the bug described above.
open event:
-1.1 warned that the items optional parameter would be removed in future Finders, and it is gone in 8.0.
-8.0 adds the with properties parameter, which sends initial values for user-designated properties along with the open event sent to the application that opens the direct object. This will only work in applications that are rewritten to support this new feature.
print event:
-1.1 warned that the items optional parameter would be removed in future Finders, and it is gone in 8.0.
application class:
-1.1 listed the application class under both the Standard Suite and the Finder Suite, listing some of the properties under the Standard Suite and all of the elements and properties under the Finder Suite, with some duplication of properties; the application class is now consolidated in the Standard Suite in 8.0, and all of the elements and properties are listed in that one place.
-1.1 listed 23 elements; 8.0 lists 26 elements. The new elements in 8.0 are clipping, clipping window and status window.
-1.1 listed 29 properties, 5 under the Standard Suite and 24 under the Finder Suite (5 were duplicated in both locations with different descriptions, so there effectively were only 24 properties); 8.0 lists 24 properties in one location. One of them, view preferences, is DEPRECATED because view preferences were global to the Finder as a whole in 1.1 but are local to each window in 8.0. There is one new property in 8.0, Finder preferences, which corresponds to the new preferences class, and one that is omitted, shortcuts.
-1.1 stated under the Standard Suite that the clipboard property was a list of anything and did not state that it was read-only, but it stated under the Finder Suite that it was a reference and is read-only; 8.0 states that it is a reference and is read-only.
-1.1 stated under the Standard Suite that the frontmost property was read-only, but it did not state under the Finder Suite that is was read-only; 8.0 does not state that it is read-only.
-1.1 stated under the Standard Suite that the selection property was a selection-object, but it stated under the Finder Suite that it was a reference; 8.0 states that it is a reference.
-1.1 stated under the Standard Suite that the version property was a version, but it stated under the Finder Suite that it was a string; 8.0 states that it is a string. 1.1 referred to the version of the Finder Scripting Extension; 8.0 refers to the version of the Finder.
-1.1 had an about this macintosh property; under 8.0 it is about this computer, but the change presumably will not break old scripts because the underlying code is the same.
-1.1 described the product version property as referring to this Macintosh; 8.0 describes it as referring to this computer.
-1.1 described the sharing starting up property more fully than does 8.0, which omits the 1.1 parenthetical (still off, but soon to be on).
-8.0 adds the clipping, clipping window and status window elements corresponding to these three classes.
-8.0 adds the Finder preferences property reflecting [v]arious preferences that apply to the Finder as a whole. This corresponds to the new preferences class.
-8.0 omits the shortcuts property.
file class:
-1.1 listed the file class under both the Standard Suite and the Finder Suite, listing one of the properties, stationery, under the Standard Suite and all of the properties, including a duplicate of stationery, under the Finder Suite; the file class is now consolidated in the Standard Suite in 8.0 and all of the properties are listed in that one place.
-1.1 listed 7 properties, 1 under the Standard Suite and 6 under the Finder Suite (1 was duplicated in both locations with different descriptions, so there effectively were only 6 properties); 8.0 lists 8 properties. The two new properties are file type obsolete and locked obsolete, both of which are DEPRECATED.
-1.1 described the stationery property as referring to a stationery file under the Standard Suite but as referring to a stationery pad under the Finder Suite; 8.0 calls it a stationery pad.
-8.0 adds the file type obsolete and locked obsolete properties, both of which are DEPRECATED.
-A bug in 8.0 results in incorrect recording of the action of setting the name of a file; the workaround is to correct the recorded script by hand.
window class:
-1.1 listed the window class under both the Standard Suite and the Finder Suite, listing all of the properties under the Standard Suite; the window class is now consolidated in the Standard Suite in 8.0 and all of the properties are listed in that one place.
-1.1 listed 10 properties; 8.0 lists 14 properties. The four new properties are popup, pulled open, collapsed and zoomed full size.
-8.0 adds a qualification to the visible property, stating that it is always true for Finder windows.
-8.0 adds the popup and pulled open properties relating to the new Finder 8.0 pop-up window feature. Setting these properties works only if the Finder is frontmost, a window is open, there is room for another tab at the bottom of the screen and the use simple menus property of the Finder preferences is false, so using it in a try block is recommended. The following properties cannot be applied to a pop-up window: size, bounds, position, collapsed, zoomed and zoomed full size. The close command returns a pop-up window to tab form. The AppleScript overview gives example scripts for automating the process of setting up pop-up windows.
-8.0 adds the collapsed property relating to the windowshade feature.
-8.0 adds the zoomed full size property, describing whether the window is zoomed to the full size of the screen. It can be set but, oddly, not read; the error message when you try to read it is quite explicit about that.
Miscellaneous Suite:
1.1 did not list the copy event; 8.0 lists it and two events formerly listed under the Finder Suite, reveal and select, under the Miscellaneous Suite.
-With respect to copy (to the clipboard), the dictionary specifically states that the Finder must be the front application. For example, if a disk icon is selected in the Finder and the finder is activated, copy puts the name of the selected disk on the clipboard. The name can then be pasted into anything, or a script editor that supports a paste reference command can paste a reference to the selected disk.
Finder Suite:
In 8.0, two events, reveal and select are moved from the Finder Suite to the Miscellaneous Suite, and three classes, application, file and window, are moved from the Finder Suite to the Standard Suite and consolidated there with the same properties that were duplicated in the Standard Suite in 1.1. 8.0 adds four new classes, clipping, clipping window, label and preferences. It omits two, group and user, because scripting of these network functions has been moved to new control panels.
put away event:
-1.1 warned that the items optional parameter would be removed in future Finders, and it is gone in 8.0.
restart , shutdown and sleep events:
-1.1 described the restart, shutdown and sleep events as relating to the Macintosh; 8.0 decribes them as relating to the computer. The 1.1 computer event was already described as relating to this computer.
application file class
-8.0 pares down the description of the scriptable property, omitting the explanation that it detects the presence of the open application (run), open document, print document and quit events only; and it corrects the grammar of the other three property descriptions.
clipping class
-New class in 8.0. It has no properties of its own but inherits properties of class file. For example, ‘tell application Finder to get name of clippings’ returns a list of all clipping files on the desktop.
clipping window class
-New class in 8.0. It has no properties of its own but inherits properties of class window. For example, ‘tell application Finder to get name of clipping windows’ returns a list of all open clipping windows (or a reference to a single clipping window if only one is open, or an error if none are open).
container class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping.
-1.1 listed 8 properties; 8.0 lists 20 properties. Two of them, previous list view and view, are DEPRECATED because view preferences were global to the Finder as a whole in 1.1 but are local to each window in 8.0. There are 12 new properties in 8.0, calculate folder sizes, icon size, keep arranged, keep arranged by, show comments, show creation date, show kind, show label, show modification date, show size, show version and use relative dates.
-8.0 adds the clipping element corresponding to this new class.
-8.0 adds the calculate folder sizes, icon size, keep arranged, keep arranged by, show comments, show creation date, show kind, show label, show modification date, show size, show version and use relative dates properties reflecting these new window-level view preferences.
-According to the overview on the AppleScript site, there is a bug with the use of icon grids in the keep arranged property: instead of set keep arranged of the_folder to true to set a container’s view options to Always snap to grid, you must set the keep arranged property to true and then set keep arranged by of the_folder to <>. For example, if your startup disk is set in the View Options dialog to Keep arranged by Name and you run the script statement, set keep arranged of startup disk to true, then get keep arranged of startup disk will return true – but if you open the View Options dialog again you will see that it has not been set to Always snap to grid as it should have been. If you follow the overview’s workaround, it will be changed. I suspect the programmers got confused by the similarity of keep arranged and keep arranged by. In Finder 8.1 this bug is still present, but you can use the constant ‘grid’ instead of ‘<>’. Unfortunately, in making this minor change, the Finder 8.1 keep arranged by property was broken. You now cannot set the keep arranged by property by constants like ‘label’ or ‘name’ but must instead use any of the following integers: 2 = ‘name’, 3 = ‘modification date’, 4 = ‘size’, 5 = ‘kind’, 7 = ‘label’ and 9 = ‘creation date’. Other values will reportedly work but are not included in the View Options dialog’s popup menu. Getting the keep arranged by property still returns a proper constant, and you can set another window’s keep arranged by property to the result.
-The view property returns the current view by constant (e.g., small). It can be set by constant or integer id, where the correspondence is:
The first six are identical to those available in 1.1; the others are new in 8.0. There is a bug in Finder 8.0 and Finder 8.1 in recording the action of setting the sort order of a list view to by label; you have to change the recorded script manually from label to label index. Another bug in Finder 8.0, fixed in Finder 8.1, resulted in a crash if a script attempted to set the sort order of a list view to a value designating a column that is currently hidden; the workaround was to set view by name, first, then set the desired show property to true, then set the desired sort order.
-8.0 sets views of individual containers, not of all views globally as in 1.1. The AppleScript overview gives an example script that automatically sets all nested folders to the view of the selected container (working around a bug in the Finder 8.0 code for searching nested folders).
-Finder 8.1 folder windows have a sort order button which toggles the order of list views. Sort order is also accessible through the new AppleScript property sort direction of class container and class container window.
container window class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping. These mirror the elements in the container class.
-1.1 listed 7 properties; 8.0 lists 20 properties. One of them, folder obsolete, is DEPRECATED. There are 13 new properties in 8.0, calculate folder sizes, folder obsolete, icon size, keep arranged, keep arranged by, show comments, show creation date, show kind, show label, show modification date, show size, show version and use relative dates.
-8.0 adds the clipping element corresponding to this new class.
-8.0 adds the calculate folder sizes, icon size, keep arranged, keep arranged by, show comments, show creation date, show kind, show label, show modification date, show size, show version and use relative dates properties reflecting these new window-level view preferences. These mirror the new properties in the container class; go to the discussion of that class for details, including bugs in the new keep arranged and keep arranged by properties as well as the preexisting view property.
-8.0 adds the folder obsolete property, which is DEPRECATED.
-Finder 8.1 folder windows have a sort order button which toggles the order of list views. Sort order is also accessible through the new AppleScript property sort direction of class container and class container window.
control panel class
-8.0 omits the 13 properties that were in the 1.1 control panel class, all of which related to global view settings.
desktop-object class
-8.0 adds the clipping element corresponding to this new class.
disk class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping. These mirror the elements in the container class.
-8.0 omits syquest from the description of ejectable media, substituting and so on in the list of examples (which now reads, floppies, CDs, and so on), presumably reflecting a laudable egalitarian recognition that Iomega and other manufacturers of removable media have been reasonably successful.
folder class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping. These mirror the elements in the container class.
group class
-8.0 omits this because this network scripting function is moved to the new control panels.
information window class
-8.0 adds the creation date obsolete, locked obsolete and modification date obsolete properties, which are DEPRECATED.
item class
-8.0 adds the description property, desribed as a description of the item. This returns the contents of a resource that should exist in every file, describing the purpose of the file for use by startup managers and the like.
-8.0 adds the creation date obsolete, locked obsolete and modification date obsolete properties, which are DEPRECATED.
label class
-This is new in 8.0, adding the ability to get and set the color and name properties of Finder labels.
-The properties of the labels class are accessed through the label 1, label 2 and so on properties of the preferences class, which is in turn accessed through the Finder preferences property of the application class.
preferences class
-This is new in 8.0, reflecting the new global Finder preferences. It has the new global delay before springing, label 1, label 2 and so on, spring open folders, use simple menus, use wide grid, view font, view font size and window properties. It also has the calculate folder sizes, icon size, show comments, show kind, show label, show modification date, show size and show version properties reflected in the container and other classes, but all of these are DEPRECATED in the global preferences class because these formerly global view preferences are now local to each container.
-The properties of the preferences class are accessed through the Finder preferences property of the application class. The Applescript overview gives an example script application for saving and applying two sets of Finder preferences.
-The delay before springing preference takes values of 12, 24, 36, 48 or 60, not 1, 2, 3, 4 or 5 as stated in the dictionary.
-The view font property takes numeric values for fonts, namely, the id of a font. You must consult a concordance to associate font names with their ids; the Finder does not provide this service.
process class
-8.0 adds the file type obsolete property, which is DEPRECATED.
-The scriptable property retains the explanation that it detects the presence of the open application (run), open document, print document and quit events only, although this explanation was omitted from the scriptable property in the application file class.
-The remote events property has a new, grammatically correct description.
sharable container class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping. These mirror the elements in the container class.
sharing window class
-8.0 adds the folder obsolete property, which is DEPRECATED.
trash-object class
-1.1 listed 15 elements; 8.0 lists 16 elements. The new element in 8.0 is clipping. These mirror the elements in the container class.
OTHER NEW SCRIPTING FEATURES New Location for the Scripting Additions Folder
The Scripting Additions folder, which used to be in the Extensions folder, has been moved to the root level of the System Folder. The motive apparently was not simply malice, since AppleScript still searches the old location for backwards compatibility. However, putting scripting additions in the new location breaks existing script editors, which can’t find the scripting addition dictionaries. Apple’s own Script Editor was upgraded with Mac OS 8, of course, and a Script Debugger 1.0.5 upgrader is available. Mac OS 8 updaters for Scripter and FaceSpan are in development. If your favorite editor has not yet been updated, leave all of your scripting additions in the old location. PreFab Player is not affected by the change in the location of the Scripting Additions folder, except that example scripts for PhotoShop and Illustrator assume that certain script libraries are installed in the old location of the Scripting Additions folder; because these are example scripts, Scott Lawton reports that they will not be upgraded for now but can be changed by users who want to place them elsewhere. QuicKeys and CLImax are among the scripting utilities which I have not yet tested on this issue.
Chris Espinosa of Apple explained it thusly in a July 24, 1997 message on the applescript-users mailing list:
Cal Simone had the following to say about it in a posting to the MacScripting mailing list and others on August 19, 1997:
Other New System Subfolders
Mac OS 8 has also moved or created several other subfolders of the System Folder, in a new attempt to bring order to the ever-expanding System Folder. Some of these, including the Application Support folder, are expressly left for developers to use any way they see fit within the implicit confines of their names. It occurs to me that the age-old question of where to put compiled AppleScript libraries now has another answer: the Application Support folder. But I’m sure others will disagree (indeed, they already have, on the applescript-users list), and chaos will prevail over order, as usual.
New Path To Command Parameters
The File Commands scripting addition has been revised so that its Path To command accepts new parameters reflecting all of the new folders defined in the Mac OS 8 System Folder, including the new location of the Scripting Additions folder. The new parameters will not be recognized under System 7. They are:
ObjectSupportLib and other libraries
The 68K Code Fragment Manager (CFM-68K) 4.0 and a number of libraries for 680x0 Macs have been moved from the Extensions folder into the System file itself. These libraries are said to include AppleScriptLib for 680x0 Macs and the bane of our existence, ObjectSupportLib (OSL). The AppleScriptLib library file is still needed on PowerPC Macs. However, the ObjectSupportLib library is no longer needed as a separate file on PowerPC Macs or 680x0 Macs. At least one reason for removing ObjectSupportLib altogether is that obsolete versions of ObjectSupportLib are automatically installed by any number of software packages, including some that come with Mac OS 8, without checking for newer versions. The obsolete versions supposedly will not be loaded into memory even if present, under Mac OS 8, to avoid the myriad problems that this situation has caused in the past.
On August 4, 1997, Ted Landau’s MacFixIt web site reported on a communication from the person at Apple who actually implemented the changes to OSL in Mac OS 8. He reported that OSL has been revised for Mac OS 8 to fix a couple of bugs, and at the same time it was rolled into the System file for both 68K and PowerPC CPUs. OSL has also been changed to use the CFM versioning mechanism to prevent older copies of the library from being loaded and used, so having an older library installed in your System Folder won’t cause problems anymore. The Mac OS 8 Technical Note confirms that the version of ObjectSupportLib now contained in the System file is 1.2.1, up a notch from the most recent version, 1.2, and that it contains code for both 68K and PPC machines.
The original draft Technical Note also said that obsolete versions of ObjectSupportLib are automatically moved to the Extensions (Disabled) folder at startup, but I have seen with my own eyes that this is not so (version 1.0.2 and 1.0.4 remained in my Extensions folder through repeated restarts). On July 29, 1997, the Macintosh Resource Page reported that Apple had confirmed that the draft Mac OS 8 Technote was in error and would be amended. Perhaps the programmers became concerned about the time when we will inevitably have to start putting newer versions in the Extensions folder once again, when the library next requires revision. (The MRP also reported that the obsolete library file must have been used by Mac OS 8, because when I tried to throw out an old version from the Extensions folder, I was told that I couldn’t because the file was in use. My own experience was just the opposite: I dragged the obsolete version to the trash and successfully emptied the trash without complaint from the system.)
It has been suggested that the Mac OS 8 fix may cause problems with some applications that need to see the ObjectSupportLib file in the Extensions folder. I am not aware of any application for which this has been verified. Perhaps any such application will be satisfied if ObjectSupportLib is placed at the root level of the application’s own folder, rather than in the System Folder. FileMaker Pro is one application that should be tested, because it was widely reported to require a particular version of ObjectSupportLib, and this need was met by placing that version in the FileMaker Pro folder.
Because old versions of ObjectSupportLib will undoubtedly continue to be reinstalled by ignorant installer software until we get to Rhapsody, I have written a small AppleScript application called Purge OSL to remove ObjectSupportLib from disks on which Mac OS 8 is installed. Purge OSL also checks to make sure the latest version of ObjectSupportLib is installed on disks on which System 7.x is installed. I was tempted to call this script AS Backwards AS stands for AppleScript; it is pronounced ay ess backwards, but don’t say it too fast in polite company. Purge OSL can be run after installing new software, or at startup from the Startup Items folder, to find and trash any version of ObjectSupportLib equal to or earlier than 1.2.1 under Mac OS 8.
New Application Types Recognized
AppleScript 1.1.2 will now recognize the new application types which are taking the place of some old-style desktop accessories, control panels and the like. AppleScript can now launch files of type ‘APPL’, ‘APPC’, ‘APPD’, or ‘appe’, whether they are 68K applications (with ‘CODE’ resources) or PPC applications (with ‘cfrg’ resources). It can also launch the Finder, which finally allows a scripter to directly quit and relaunch the Finder (for example, to remove desktop files and cause the Finder to rebuild the desktop). All of these file types may be used as targets for AppleScript tell commands.
Pretty Dialog Boxes
The dialog boxes for AppleScript and the Display Dialog scripting addition now sport the new Apple platinum Appearance when running on a Mac OS 8 machine.
Keyboard
The Keyboard control panel application provides user interface services for configuring the keyboard menu (displayed when more than one keyboard layout is selected) and adjusting various settings for the computer’s keyboard. It is scriptable, and additional AppleScript support for keyboard options is provided by the Keyboard scripting addition so that scripts are not required to launch the Keyboard control panel to access Keyboard services.
Connect To… 1.0
Connect To…, installed by Mac OS 8 in the Apple Menu Items folder, is described in Technote 1102 Mac OS 8 as a new small AppleScript applet. Sure enough, although the file type for this item is ‘APPD’, its creator is ‘aplt’ for applet. It provides quick access to an internet URL; URLs are dispatched through the Internet Config extension.
Desktop Pictures 1.0
Desktop Pictures replaces the Desktop Patterns control panel. Desktop Pictures allows the user’s choice of image files, in any of several formats stored in separate picture files, to be displayed as the desktop background, as well as continuing the old Desktop Patterns functionality. It supports a set of simple AppleScript commands.
A very nice FaceSpan application, Desktop Gallery, has already been written to take advantage of the scriptability of the Desktop Pictures control panel. It allows the user to change desktop pictures under AppleScript control at user-specified intervals and with a randomize option, much like the popular Decor extension.
Information on scripting in Mac OS 8 is beginning to appear in Apple’s Tech Info Library (TIL), as well as in information released with new products.
Location Manager
The Location Manager was released for Powerbooks before Mac OS 8 was released and does not require Mac OS 8, but with Mac OS 8 it became available for use on all machines for the first time. With Mac OS 8.1 comes a new version 2.0.1 of Location Manager. The following Q&A’s, which were excerpted from Apple Location Manager: Frequently Asked Questions, TIL Article ID 30118 created 7/29/97, are still pertinent:
Question: Does the Location Manager use AppleScript to do it’s magic?
Answer: No, you do not have to have AppleScript enabled in order to use the basic functions of the Location Manager. If you choose to have an AppleScript application be an Auto-Open Item then you will need to have AppleScript enabled. Also if you wish to use the Location Manager’s Apple Guide then you will need to make sure AppleScript is enabled.
Question: There is no Module written to do what I need it to do?
Answer: Remember that one of the Modules is Auto-Open Item. If what you need to do can be accomplished by using AppleScript, you can create an AppleScript application and then use the Auto-Open Item Module to open it up when you switch Locations.
Question: Is the Location Manager scriptable?
Answer: Yes, it is scriptable but not recordable. It supports the Required Suite (open, print, quit, run) and defines a Class called Location. Which can be used to get the Current Location selected, and to change the Current Location.
Question: Can I have the Location Manager change to a certain Location every time the computer starts up?
Answer: Apple Location Manager only changes system settings when you tell it to; it does not automatically change settings at startup (although you can use Preferences in the Edit menu to have the program prompt you to change settings). If you want Apple Location Manager to switch to a specific location each time the computer starts up, you can create an AppleScript script that performs that task. Put the script in the Startup Items folder and the location you want will be set at startup. Open the location you want to use at startup, then create the script below. Using the Script Editor application, type the following lines (The following example is from the Apple Location Manager Read Me file):
tell application "Finder"
open file ((control panels folder as string) & "Location Manager")
tell application "Location Manager"
set current location to location "snd"
end tell
end tell
Copy the script above exactly and substitute the name of your location for snd; for instance, type Sample if you want the Sample location to be used each time you start up. When finished typing the script, launch Location Manager then compile the script.
Note that the second line of the sample script is not necessary in Mac OS 8, which recognizes the new control panel applications.
Apple Data Detectors
Apple Data Detectors (ADD) is a new Mac OS 8, PowerPC-only technology from Apple which enables users to act on Finder items or selected application data using a control-click to bring up a system-level contextual menu. The key concept underlying ADD is that a user need not select precisely the text desired, but can simply swipe at a long text passage; ADD will pick out all instances of text within the selection that meet criteria specified by installed detectors. The first implementation of ADD, Internet Address Detectors (IAD), was released on September 8, 1997. New version 1.0.2 of the ADD installer, which adds the ability to turn off ADD as well as all other contextual menus in specific applications that use control-click for other purposes, was posted in December 1997 (and temporarily removed in January 1998 to fix an unspecified problem). Along with the new version of ADD, a new version of Internet Adress Detectors, version 1.0.1, and U.S. Geographic Detectors 1.0 were released, and an installer for a third detector, the Currency Detector, was promised shortly.
ADD actions are nothing more than AppleScript scripts, though they are sometimes disguised with a custom icon. To write scripts that work with ADD, you must have the Apple Data Detectors Scripting scripting addition, which supplies some required new terminology. The ADD installer and the ADD SDK, a separate download, include extensive documentation, the Apple Data Detectors Scripting scripting addition for creating actions, and an editor for creating new detectors (which are not based on AppleScript).
The Currency Detector will include actions (AppleScript scripts) for recognizing several national currency notations and checking exchange rates on the internet. The U.S. Geographic Detector recognizes city and state names in various formats, and it includes actions for going to the appropriate map on the Yahoo site and looking up zip codes on the U.S. Postal Service site. The Internet Address Detectors, previously available in an earlier version, recognize web, e-mail, ftp and other internet address formats, and they include actions such as going to a site and entering a site in an address book or bookmark file. Michael Schürig of Tortoise-Additions fame has written an IAD action that improves on Apple’s own action for bookmarking URLs in MSIE, as well as his CMScript, which allows users to install their own general-purpose scripts in contextual menus even apart from the data detector function. IAD actions for URL Manager Pro, my personal favorite web bookmarking utility, have also become available. The PageSpinner Extensions Pack has brought three new IAD actions to this scriptable text-based HTML web-authoring application. Other actions are cropping up almost daily, it seems.
Speech Recognition
Speech recognition is not new in Mac OS 8, but it seems worth mentioning that most of the commands in the Speakable Items folder are simply AppleScript applications with custom icons. You can write your own scripts, paste the speakable items icon into their Get Info dialogs if you like, give them a name that is a suitable spoken command, and place them in the Speakable Items folder.
This is the AppleScript 1.1.2 bug-fix list, quoted verbatim from Macintosh Technote 1102, with my comments:
When the Event Log exceeds 20,000 characters, excess characters are now lost off the top to make room for new events and results. This eliminates the -20013 error that occurred on logging many repetitive, long, or ongoing processes.
Repeatedly doing a Save As to an applet tended to accumulate multiple resources of type PREC and others, because AddResource was being called regardless of whether that resource already existed. This has been fixed in Script Editor 1.1.2.
The AppleScript symbol table in version 1.1.1 and earlier accommodated a maximum of 1,024 symbols. In version 1.1.2 this is expanded to 4,096 symbols.
Concatenating a record with an empty vector, e.g. {a:1, b:2} & {}, caused a crash in version 1.1.1. This is fixed in 1.1.2.
Execution of an applet caused, under certain conditions, memory location $0006 to be overwritten, causing incompatibility problems with specific third party applications. Applets that are reopened and saved with AppleScript 1.1.2 will no longer overwrite this address.
Multiple-character text item delimiters caused the machine to hang in an infinite loop on operations like count text items of and text item 2 of. This has been fixed in AppleScript 1.1.2. However, it is still impossible to set text item delimiters to a list of multiple items. Here is a useful example of what you can now do with a multi-character text item delimiter:
set theURL to "http://www.mydomain.com/mydirectory/"
try
set saved to AppleScript's text item delimiters
set AppleScript's text item delimiters to {"//"}
set theProtocol to text item 1 of theURL
set AppleScript's text item delimiters to saved
return theProtocol
on error
set AppleScript's text item delimiters to saved
end try
In AppleScript 1.1.1, the test to see whether a script could be reloaded into memory was faulty, and would not allow loading of scripts that had been created and saved under identical circumstances. This has been fixed in 1.1.2.
Certain numbers (such as 1310.4) cannot be represented with full accuracy as floating point numbers. AppleScript 1.1.1 was displaying these numbers with too much precision, so compilation and decompilation of 1310.4 returned 1310.400000000001. An attempt has been made to fix some of these cases in AppleScript 1.1.2, and efforts are being made to remove this problem altogether in AppleScript 1.2. NOTE that this change in behavior may break some scripts that relied on the inaccurate numbers returned by AppleScript 1.1.1 (1.1.1?!?), or require precision beyond the 12th significant digit.
The method of locking handles holding scripting addition data was not suited for re-entrance. This has been fixed in 1.1.2, so that a scripting addition may be called while it is being called by another process.
The English syntax for AppleScript required the possessive property form (for example: AppleScript’s version) to be lower-case. AppleScript 1.1.2 allows an uppercase S (for example: APPLESCRIPT’S VERSION), to be accepted. It also supports case-insensivity for DOESN’T.
In AppleScript 1.1.1, the bytecode Program Counter for the runtime engine was left uninitialized, and a routine to set its new value calculated the offset between the new value and the old. In machines with >768Mb of memory, this offset overflowed a 30-bit signed integer and resulted in a numeric overflow error, preventing anything from being compiled. The program counter is now initialized to 0, and the offset is not calculated when the PC is 0, so this error should not happen in AppleScript 1.1.2 and later.
The month property of a date type should be one of {January, February…} Setting this to a number mistakenly resulted in a Stack Overflow error. In 1.1.2 it results in a more normal Can’t make into the expected type error result.
Quitting the Script Editor, then canceling the quit, caused a crash, because the data structures for the Results and Log windows were already disposed. This has been fixed in Script Editor 1.1.2.
Mac OS 8.1 introduces the following additional bug fixes, according to Apple Technote 1121 released on January 30, 1998. Some of these apparently fix bugs that were never previously noted in public. These are verbatim excerpts from the Technote:
The typeIconFamily data type is once again supported.
Creating folders and renaming objects will now record properly.
A copy operation with replacing conflicts no longer fails.
The support for entire contents has been rewritten completely and should be more reliable in general.
Setting a view which has not been enabled in the View Options dialog no longer causes unpredictable behavior.
Support for the kAEFinderSuite/kAESync (‘fndr’/‘fupd’) event now conforms more closely to that of Finder 7. Because of fundamental differences between Finder 7 and 8, there is no way to make the behavior absolutely identical.
File type comparisons are now case-sensitive.
Duplicate and move operations with routing suppressed now works correctly.
Several memory leaks were eliminated, some of which existed prior to Finder 8.0. Several involved whose clause resolution and disposing of the descriptors used to represent the search specification. Another leak had to do with token handles in token descriptors not getting disposed when the token did.
Attempts to resolve a broken alias will now reliably produce an error -5018 (afpObjectNotFound).
Support for whose clauses now works properly with respect to processes. (This is not quite so. See my quibble, below.)
AppleScript 1.1.2, which was introduced with Mac OS 8.0 and is still provided with Mac OS 8.1, appears to be relatively free of bugs. Finder 8.0’s AppleScript support, however, had a number of serious bugs, many (but not all) of which have now been fixed in Finder 8.1. Apple posted a list of the Finder 8.0 bugs on August 7, 1997, although additional bugs have been reported to Apple since then. Here is a summary of the items on Apple’s published list as well as from other sources, marked to show bug fixes (marked FIXED IN FINDER 8.1) and still-existing bugs (marked UNCHANGED IN FINDER 8.1), as well as new bugs in Finder 8.1 (marked NEW IN FINDER 8.1). Workarounds for those that have not been fixed in Finder 8.1 are provided on the AppleScript site for bugs listed there, and here for others.
On June 25, 1998, Gordon Paynter reported a Finder recording bug in Mac OS 8.1, when recording the act of copying the name of a Finder item. To see the bug in action, open a new window in your script editor and turn on recording. Then copy the name of a file in the Finder, either by selecting the item or its name and choosing Copy from the Edit menu or pressing command-c. When you turn off recording, you will see that the copy action was recorded in the form of a raw event, <>. The script as recorded will not run. If you manually edit the last line of the recorded script to ‘copy selection’, it will compile and run properly and put the name of the selected item onto the clipboard. (Cutting the selected name of a Finder item records as 'set name of selection to ', but only if you take care to select the item’s name in the Finder, not just the item itself, which is correct from the Finder’s viewpoint. But running that script will not place the original name on the clipboard. Note that the Finder’s dictionary does not purport to support the ‘cut’ event, but it does purport to support the ‘copy’ event. What is the correct Finder event code for ‘copy’?)
On June 25, 1998, Gordon Paynter reported a Finder recording bug in Mac OS 8.1, when recording the act of deselecting some items in a Finder window where all items had previously been selected. Gordon reports that the bug also existed in Mac OS 8.0. To see this bug in action, open a new window in your script editor and turn on recording. Then open a folder that contains several items, choose Select All from the Edit menu, and perform some action on the selection such as setting the labels of the selected items. Then deselect some of the items (either by shift-clicking to deselect them, or by dragging a selection rectangle to select a subset of them), and perform another action on the subset such as setting their labels to something else. When you stop recording, you are likely to find that the second act of selection (or deselection) is recorded as ‘select every item’ even though only some items were left selected. This happens whether the window is in list view or in icon view. The key precipitating factor appears to be the initial Select All command; if you start by selecting a subset of the items in the folder, then deselecting some of those, the bug does not seem to bite.
On June 22, 1998, Marco Balestra reported that the Finder’s close command does not work properly with filter references in Mac OS 8.1. For example, ‘close every window whose popup is false’ only closes one of the windows meeting this criterion. I have verified this bug with other filter reference forms, such as ‘whose name contains untitled’ and ‘whose name is not X’. I have also verified it with windows, container windows and folders. Since similar Finder commands that do not remove windows work properly, I suspect that this bug results from improper tracking of window indexes while removing windows from the list.
On March 9, 1998, Eric Hellman reported that Finder 8.0 and 8.1 cannot set the owner and group access properties for sharable containers. I have not fully explored the nature and extent of this problem, but I have verified that there are serious problems. After turning on file sharing and creating a fictitious user named Soupy in the Users & Groups control panel, I cannot set the owner of a test folder to Soupy by running this script: 'tell application Finder to set owner of folder Test Window of desktop to Soupy. I get no error, but the owner remains what it was originally set to (Bill Cheeseman, on my machine). If I manually set the owner to Soupy, I cannot set it back to Bill Cheeseman from a script. Also, attempting to set owner privileges fails with error number -10006.
In early February 1998, Eric Grant reported that the Finder 8.1 ‘keep arranged by’ property of containers and container windows is broken. I believe it worked correctly in Finder 8.0. It may have been broken by the partial fix to the Finder 8.0 bug in the ‘keep arranged’ property. To recapitulate, the official AppleScript site reported on August 7, 1997 that a two-step process is required to set the Always snap to grid view option of a container window: after setting the ‘keep arranged’ property to true, you must also ‘set keep arranged by of to <>’. This is a bug, and it remains UNCHANGED IN FINDER 8.1 except that you can now say ‘grid’ instead of ‘<>’ in the second statement. NEW IN FINDER 8.1: Unfortunately, in making this minor change it appears that Apple broke the mechanism for using any other constant, such as ‘label’, to set the ‘keep arranged by’ property of container windows. In summary: if you ‘get keep arranged by of ’, you receive a constant such as ‘label’, ‘name’ or ‘creation date’, depending on how you have set the icon arrangement of the window in the Finder’s View Options dialog. Furthermore, you can immediately ‘set keep arranged by of to result’, and it will work. However, trying to set the ‘keep arranged by’ property of a container window directly with a constant like ‘label’ or ‘name’ generates an error. The workaround is to set it using an integer, using the following values in place of the corresponding constant: 2 = ‘name’, 3 = ‘modification date’, 4 = ‘size’, 5 = ‘kind’, 7 = ‘label’ and 9 = ‘creation date’. All other values are illegal.
On January 30, 1998 Nigel Stanger reported that in Finder 8.1 you cannot permanently change the position of a Finder window. The same is true of changing its bounds. Setting an open window’s position or bounds to a new value does in fact move the window, but if you close and reopen it the original position or bounds will be used. Calling the ‘update’ command does not help.
On January 28, 1998, Eric Grant reported a bug in the Finder’s implementation of filter references when used to compare dates of Finder items. Date comparisons using the comes before and comes after comparison operators in whose clauses sometimes return incorrect results. I find that some dates consistently trigger the error while others do not, but I have not been able to divine a consistent principle to explain the error; for example, files with creation or modification dates of 8/3/97, 10/11/97 and 10/12/97 trigger the error when compared with ‘current date’ or with ‘date 1/1/98’. To see the bug in action, use this statement in a script until you find a file with an offending date earlier than 1/1/98: ‘get every file of selection whose modification date comes after date Thursday, January 1, 1998 12:00:00 AM’. This bug was apparently present in earlier versions of the finder, and I have confirmed that it remains in Finder 8.1. Because this bug does not affect direct date comparisons without filter references, the workaround is to use a repeat loop. UNCHANGED IN FINDER 8.1.
In a November 17, 1997 communication on the applescript-users mailing list, Chris Espinosa of Apple confirmed that Finder 8 sends the file list parameter to the ‘oapp’ event in a different order than System 7.6 and earlier. The Finder team knows about this and has prepared a fix that may be rolled in to the next release of the Finder. The truth is that in icon views, previous Finders have provided the list in temporal order of selection, but in list views, the list is provided in the sort order of the list. Note that the sort order of the list considers the entire pathname, not just file names, so the file ‘Hard Disk:Fred’ will sort AFTER ‘Hard Disk:Folder:Herbert’. In Finder 8, the file list is passed in the order in which they are retrieved from the file system, which differs from file system to file system; in HFS it’s by ASCII sort of name order, in other file systems it could be by creation date or it could be nondeterministic. We are looking at changing Finder 8 to pass the list of files in order selected in all cases, both icon and list views. In most cases, selection order in list views can be made to match list order by selecting sequentially from the top down or using Select All and deselecting unwanted files. I do not fully understand this issue, but I take the following excerpt from Apple Technote 1121 to suggest that this issue may be FIXED IN FINDER 8.1: Finder 8.1 honors the order in which a group of icons are selected. The order can be important for subsequent commands to that group, like a Print or Open command.
On September 3, 1997 Jim Yost brought to my attention the fact that my Close Background Windows script no longer works under Finder 8.0. The cause appears to be a bug in Finder 8.0 and Finder 8.1 which makes it impossible to get the index of every window. For example, ‘every window whose index is not 1’ generates an error. The workaround, as with similar Finder bugs, is to use a repeat loop.
Setting the list view option of a container window to a column that is hidden caused a crash. FIXED IN FINDER 8.1.
A statement like ‘first application process’ returns a process reference under Finder 8.0, as expected. However, if you add a filter reference to the statement, such as ‘first application process whose creator type is quil’, it returns the process as a single-item list. This appears to be another bug in the Finder 8.0 scripting implementation. The workaround is to call for ‘item 1 of (first application process whose creator type is quil)’ if you know you’re running under Mac OS 8. [This is an AppleScript Sourcebook exclusive.] UNCHANGED IN FINDER 8.1.
Attempting to get the ‘original item’ of an orphaned alias file generates a different error number under Finder 8.0 than it did under previous Finders. Under Finder 8.0, the error message is An error of type 32768029 has occurred, and the error number is 32768029. These numbers are obviously bogus. It reportedly sometimes instead returns error number -2702, which is the errOSANumericOverflow error signaling a numeric overflow. Under earlier versions of the Finder, it was common practice to test for error number 5038, which, being a positive rather than a negative number, was apparently also bogus; real system error result codes are negative. For the time being, scripts that check for missing original items should test for at least the first two error codes, and perhaps -2702, as well. Apple has reportedly reproduced the error and logged it against the Finder as bug ID #1678205. [First reported on the MacScripting mail list by Steve Herman at NASA’s Marshall Space Flight Center.] FIXED IN FINDER 8.1: It now returns error number -5018. This is the afpObjectNotFound error code (AFP Object not found). The error message returned by AppleScript is not very informative (An error of type -5018 has occurred). Error number -1728 is returned if the original item is in the trash.
Finder 8.0 is also unable to coerce an alias to the Desktop Folder into a Finder item. The Choose Folder command from Apple’s Choose File scripting addition allows a user to select the Desktop Folder, returning an alias to it. Any attempt to coerce this to a Finder reference generates spurious error no. 32768029. This is the same spurious error number that is generated when you try to get the original item of an orphaned alias under Finder 8.0, so these bugs are presumably related. This may also have something to do with all the other bugs involving the desktop. Chris Espinosa pointed out to me that the desktop folder is a fictitious entity, which fits the pattern. A workaround is to place any command that might try to save or move a file to the desktop into a try block that tests for error number 32768029, and on that error explicitly tell application Finder to save or move it to desktop (but make sure this is not an orphaned alias error, which it will not be if the path was obtained from the user with the New Folder scripting addition). [This is an AppleScript Sourcebook exclusive.] Partially FIXED IN FINDER 8.1: Running the statement ‘tell application Finder to get (choose folder) as reference’, and clicking on the ‘choose Desktop Folder’ button after navigating to the desktop in the resulting dialog, now returns ‘alias Sucia:Desktop Folder: of application Finder’ on my system. However, Ed Stockly has noticed, as described in his communication to the MacScripting mailing list on March 15, 1998, that there are other bugs regarding the desktop in Finder 8.1. My tests narrowed them down to the following: (1) Getting ‘name of desktop’ returns Desktop, when it should return Desktop Folder. (2) Similarly, coercing ‘desktop’ to an alias returns ‘alias :Desktop’, without the word Folder or a trailing colon; it should return ‘alias :Desktop Folder:’. See Desktop Madness for an explanation of why this is a problem and suggested workarounds. (3) Getting ‘container of desktop’ returns ‘<<class ****>> Finder’. This is clearly spurious, as the desktop can have no container. I don’t know whether these bugs were present in Finder 8.0.
The ‘duplicate’ event is supposed to autoroute special files, such as system extensions or scripting additions, to the corresponding special subfolder of the System Folder when the new ‘routing suppressed’ parameter is set to false (the default value) and the file is duplicated to the ‘system folder’. This does not work; instead, the script fails with a spurious user canceled error. The workaround is to duplicate the file to the correct subfolder explicitly. [This is an AppleScript Sourcebook exclusive.] Apple has reported to me that this bug has been fixed for the next release. FIXED IN FINDER 8.1. And scripting additions are autorouted to the new Scripting Additions folder at the root level of the System Folder, not to the old Scripting Additions folder in the Extensions folder.
The new ‘positioned at’ parameter to the ‘move’ event works but does not place the moved item where expected. The origin, or {{0, 0}}, should be at the upper left corner of the window’s content area, which does not include its border, title bar or information pane. However, moving an item to {{0, 0}} places it partially outside the content area, to the left and upwards. The old ‘position’ property of class ‘item’ returns a result under Finder 8.1 which is horizontally 16 pixels to the left and vertically 28 pixels higher than desired. [This is an AppleScript Sourcebook exclusive.] UNCHANGED IN FINDER 8.1.
Attempting to ‘get the id of every disk’ fails. [This bug was first reported and dissected in a thread on the MacScripting Mailing List from July 28 to 30, 1997.] UNCHANGED IN FINDER 8.1.
Attempting to get ‘every font suitcase in the entire contents of the fonts folder’ returns an empty list or a spurious error. Getting every suitcase at the root level of the fonts folder works correctly; it is only the effort to include nested folders within the fonts folder that fails. FIXED IN FINDER 8.1.
Attempting to get ‘every folder of entire contents of (choose folder)’ reportedly sometimes returns an empty list. This is apparently fixed in Finder 8.1. At least, I have not found a counterexample after some time spent testing. It’s hard to be sure, since returning an empty list was described as an ‘occasional’ error in Finder 8.0. Taking a chance, I say this is FIXED IN FINDER 8.1. I wonder if it was ever really a bug? After all, if there really were no folders in the chosen folder, one would expect to get an empty list.
It is impossible to set the icon of a file in the Finder. No workaround is available. FIXED IN FINDER 8.1.
An alias file cannot be created on the desktop pointing to a file that is already on the desktop. FIXED IN FINDER 8.1 (if this was really a bug in Finder 8.0; the sample script on the AppleScript site contains a syntax error which could explain why it did not work).
Attempting to ‘get creator type of every process’ returns a list of classes rather than a list of strings. [Joe Barwell reported this on the MacScripting mail list on August 1, 1997, before it appeared on the AppleScript site.] The same problem occurs when attempting to ‘get file type of every process’. It is not possible to work around this bug by searching for the desired class. As with many of the Finder scripting bugs, the only workaround is to build the desired list using a slow repeat loop, as shown below. UNCHANGED IN FINDER 8.1.
tell application "Finder"
set creaList to {}
repeat with x in every process
set end of creaList to creator type of x
end repeat
end tell
creaList
Attempting to get ‘path to desktop’ or ‘path to fonts folder’ within a Finder tell block fails. FIXED IN FINDER 8.1 as to ‘path to desktop’, but UNCHANGED IN FINDER 8.1 as to ‘path to fonts folder’ (the latter returns a disk wasn’t found error).
Recording Bugs
There are several bugs in recording user actions under Mac OS 8. For all of them, the only workaround is to edit the script after recording it. Examples of the incorrect generated code and the correct edited code are given on the AppleScript site.
Changing the names of items in the Finder. FIXED IN FINDER 8.1.
Setting the Grid Spacing property in Finder Preferences. UNCHANGED IN FINDER 8.1.
Setting the Snap to Grid property in View Options. FIXED IN FINDER 8.1.
Recording the act of setting the column by which to sort a window in list view to by Label still incorrectly generates a script that attempts to set the ‘view’ property of the container window to ‘label’, which will not work when run. Manually edit it to ‘label index’. I assume the reason for this error is that, if you ‘get’ the view property of the same container window, it returns the constant ‘label’, not ‘label index’. Attempting to set the same window’s ‘view’ property to ‘result’ fails. UNCHANGED IN FINDER 8.1.