Tuesday, January 17, 2017

#1 2001-09-25 09:07:58 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)


Before using new features of AppleScript, careful writers of scripts intended for public distribution will want to determine which version of AppleScript is present on the user's machine. This task has become more complicated with the advent of Mac OS X, due only in part to the fact that different flavors of AppleScript 1.6 are installed in the Classic environment and in the Mac OS X environment. In addition, unfortunately, two bugs in Mac OS X 10.0 make the task still more difficult, especially if what you want is a script that will run correctly in the Classic environment as well as under all other versions of the Mac OS.

The standard technique for determining the version of AppleScript in Mac OS 9.1 and earlier utilizes the Finder's Computer command, as explained in The AppleScript Sourcebook's report on AppleScript 1.3.4 (the technique was slightly modified for AppleScript 1.5.5, in a backward-compatible fashion). Although the Computer command has been eliminated from the Finder's dictionary both in the Mac OS X environment and in the Classic environment, a new System Attribute command that is almost identical has been added to Standard Additions in the Mac OS X environment. As a result, after tweaking it to work around the two new bugs, the basic approach of the standard technique continues to work in Mac OS X. Apple's discussion of the new System Attribute command does not address the bugs described here.

A first cut at adapting the standard technique for use in Mac OS X simply eliminates the Finder Tell block, as shown in the following script. The integer, 17826144, stands for version 1.6, in Apple's decimal-coded hexadecimal versioning scheme.


if system attribute "ascv" is greater than or equal to 17826144 then
        -- statements using AppleScript 1.6 or newer
       -- statements using older versions of AppleScript
end if

However, to enable this script to run under older versions of the Mac OS, as well, where Standard Additions did not implement the System Attribute command, it must still be enclosed in a Finder Tell block. Apple cleverly engineered the new System Attribute command so that it uses the same raw event code internally that was used by the Finder's Computer command. As a result, if you enclose the System Attribute command in a Finder Tell block and run the script on an older system without recompiling it, it will automatically invoke the Finder's Computer command and return the correct result. (To prove to yourself that the codes are identical, write the above script in the Mac OS X Script Editor using the Computer command instead of the System Attribute command. When you compile it, computer will change to system attribute. If you then move the compiled script to a Mac OS 9.1 or older machine and compile it with an older version of Script Editor, it will revert to computer.) Enclosing the System Attribute command in a Finder Tell block is harmless when a script is run under Mac OS X so, whenever backward compatibility might be required, it is advisable always to enclose a call to System Attribute in a Finder Tell block. In short, the standard technique for determining the version of AppleScript still applies in Mac OS X except for two problems.

The first bug that mars this very nice arrangement causes the System Attribute test for AppleScript 1.6 to return an incorrect value when run in the Mac OS X environment. Apple discovered this issue too late to correct the error before releasing Mac OS X for production, although it is mentioned in an AppleScript bug list on the Developer Tools CD. The command 'System attribute "ascv"' returns 17826128, which in decimal-coded hex is 01100150, meaning version 1.5. It should return 17826144, which is the integer equivalent of decimal-coded hex number 01100160, meaning version 1.6. (If you run the same test with the promised AppleScript 1.6 upgrade installed on a machine booted directly into Mac OS 9.1, I believe it will return the correct result.)

To work around this bug and test for AppleScript 1.6 in the Mac OS X environment, you can test the version of the system that is currently running in addition to testing the AppleScript version, but you need do so only if 'System attribute "ascv"' returns 17826128. If the system version is 10.0 or greater (that is, 'System Attribute sysv' returns 4096 or greater), then you can be confident that AppleScript 1.6 or newer is running, not AppleScript 1.5.

The following handler covers all of these angles:


on AppleScript16OrNewer()
   tell application "Finder" to get system attribute "ascv"
   if result is greater than or equal to 17826144 then
       return true
   else if result is equal to 17826128 then
   tell application "Finder" to get system attribute "sysv"
       return (result is greater than or equal to 4096)
   return false
end if
end AppleScript16OrNewer

Unfortunately, however, a second bug prevents a script that uses this handler from running under AppleScript 1.6 in the Classic environment of Mac OS X, so still more tweaking is required. The version of Standard Additions 1.6 that is installed in the Classic environment does not include the new System Attribute command. In addition, the Computer command has in effect been removed from the Finder's dictionary in the Classic environment, because the Classic environment uses the Finder 10.0 dictionary. Because of this confluence of dictionary changes in the Finder and Standard Additions, neither the Computer command nor the System Attribute command will compile to executable code if you are using Script Editor in the Classic environment. More seriously, such a script, if compiled under another version of the Mac OS, will error when run in the Classic environment. You therefore cannot run a script in Classic using the standard technique without yet another embellishment. (I brought this bug to Apple's attention a week before Mac OS X was released to the public. I imagine it can be fixed rather easily, perhaps by adding the System Attribute command to Standard Additions for the Classic environment. Udpates to Mac OS X are rumored, possibly as early as a week after the initial release of Mac OS X. If this bug is fixed promptly, the following workarounds will no longer be necessary.)

The trick is to trap for the error that is generated when the unimplemented Computer or System Attribute command is run in the Classic Environment, error number -1708. The following handler is the new AppleScript Sourcebook-recommended standard technique for determining whether AppleScript 1.6 or newer is present. It cannot be compiled in the Classic environment unless you substitute the raw event code for the System Attribute command, but it will run there and return the correct result. Note, however, that it is not foolproof; it assumes that nobody would install an older version of AppleScript in the Classic environment. It is likely to continue to work after Apple fixes these bugs in a later release of Mac OS X.


on AppleScript16OrNewer() try
   tell application "Finder" to get system attribute "ascv"
   if result is greater than or equal to 17826144 then
       return true
   if result is equal to 17826128 then
   tell application "Finder" to get system attribute "sysv"
   return (result is greater than or equal to 4096)
       return false
   end if
on error number -1708
   return true
end try
end AppleScript16OrNewer

There are workarounds if you must use the Classic environment to write your script. You can, for example, write and compile a script with the Classic Script Editor using the raw event code, <<event fndrgstl>>; the resulting script will run in the Mac OS X environment and in Mac OS 9.1 and earlier, but it will not run in the Classic environment. A workaround that will run in the Classic and Mac OS X environments and under Mac OS 9.1 and earlier is to get 'AppleScript's version'. Note, however, that this returns a string (e.g., 1.6) instead of the familiar decimal-coded hex value returned by the old Computer command and the new System Attribute command. Comparison of AppleScript version strings against a target string value must rely on alphabetical ordering (this should work correctly until AppleScript reaches version 10). Alternatively, you can use the Info For command from Standard Additions to get the Short Version property of the AppleScript system extension under the Classic environment and Mac OS 9.1 and earlier. However, this requires checking the Mac OS X AppleScript.component file separately, if the script is to work in the Mac OS X environment, too. Although the Short Version property can be coerced 'as real', it must be coerced 'as string' in order to deal, for example, with AppleScript 1.5.5, because 1.5.5 is not a number. The most satisfactory workaround is probably to write all your scripts in the Mac OS X environment. However, if your Mac OS X script needs to use scripting additions or scriptable applications that are available only in the Classic environment, you will face additional complexities, including figuring out how to use the Using Terms From construct described above.

After all of this work to ensure backward compatibility of the version test, you are still left with one potentially serious problem: existing older script applications. If an older script saved as a classic script application (i.e., not as a Mac OS X Applet) is run on a Mac OS X machine, it will automatically run in the Classic environment. Since neither the Finder's Computer command nor the System Attribute command exists in the Classic environment, the script will fail with runtime error number -1708, 'ascv' doesn't understand the <<event fndrgstl>> message. This will happen with all older applets that were written using the Finder's Computer command, including the version-testing technique recommended here over the last several years, as well as with new Classic applets using the System Attribute command written in the Mac OS X environment. This is why Apple must fix this bug promptly. In the meantime, if you have editing access to such a script, you can fix it in one of two ways: by recompiling it as a Mac OS X applet so that it will run in the Mac OS X environment, or by editing it to test for error number -1708 and concluding, if the error is trapped, that the script is running in the Classic environment of Mac OS X. If you don't have editing access to the script, it simply won't work on a Mac OS X machine, despite the lengths to which Apple has gone to provide the Classic compatibility environment, and there is nothing you can do about it except wait for Apple's bug fix. I don't know how many existing applets fall into this category or how essential they may be to their users, but it is a potentially serious backward-compatibility problem for the time being.

Here is a handler that can be used to determine whether a script is running in the Mac OS X environment, or in the Classic environment, or in Mac OS 9.1 standalone. It is offered only as a starting point. It does not take account of the possibility that it might be running on an older or newer system, nor of the possibility that Apple will fix the bug whereby neither the System Attribute nor Computer commands exist in the Classic environment. Refine it to suit your purposes and use it with care.


on MacOSVersion()
   tell application "Finder"
           get system attribute "sysv"
           if result is equal to 4096 then
               return "Mac OS X environment"
           else if result is equal to 2320 then
               return "Mac OS 9.1"
           end if
       on error number -1708
           return "Classic environment"
       end try
   end tell
end MacOSVersion

Filed under: Finder



#2 2001-09-25 09:10:39 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)


As with Mac OS X generally, users will have to get used to a new and unfamiliar directory structure relating to AppleScript. Helpfully, the Path To command in the Standard Additions scripting addition can be used to generate a path to some AppleScript-related folders and applications, as well as other important system locations. For example, 'path to scripting additions' (or 'path to scripting additions folder') returns an alias to the Scripting Additions folder where Apple's scripting additions are located and available to all users of the machine; namely, alias <Mac OS X disk>:System:Library:ScriptingAdditions:. For additional Path To parameters, see Standard Additions scripting addition.

Apart from the fact that all of the locations for system software are new, the most startling change from the classic Mac OS is that there can be many copies of specific system folders in Mac OS X. To understand this, you must become familiar with the basic Mac OS X notion that each user on this multiuser operating system has his or her own Home folder, which contains Documents, Library and other subfolders whose contents are available only to people who log in as that user (and to the system Administrator). This is known as the user domain. The Library folder is particularly interesting from an AppleScripter's point of view, because this is where a user's personal system-related items are located, such as scripting additions. There are also Library, Applications and other folders at the root level of the Mac OS X disk; the root-level, or main, Library folder is where system-related software available to all users on a single computer can be installed, including scripting additions. This is known as the local domain. There is also a Library folder in the System folder at the root level of the Mac OS X disk, where Apple-installed system software is located, including scripting additions; users cannot alter the contents of folders in this System domain. Finally, there may be a network domain where Applications, Library and other folders exist that are available to users from a network server. Scripting additions can be installed here, as well. Not all locations are visible or available to all users.

Here are the important Mac OS X AppleScript locations:

Script Editor resides in the AppleScript folder in the Applications folder at the root level of your Mac OS X disk, where it is available to all users. Scripters may find it convenient to drag the Script Editor icon to the Dock so that it is more easily available, unless and until they switch to some other editor. The Script Editor Help command in its Help menu takes you to the AppleScript Help topic using the Apple Help Viewer. The Open Dictionary command in Script Editor's File menu opens a dialog listing available scriptable applications and scripting additions in alphabetical order. Classic scripting additions apparently are not included in the list, but scriptable Classic applications are listed (including some, such as iTunes, that have empty 'aete' resources). Having the scriptable applications listed in this manner makes it much easier to open dictionaries, since you don't have to dig through a folder hierarchy to find them. Each user's Script Editor preferences are in the com.apple.scripteditor.plist file in the Preferences folder of the Libary folder in the user's Home folder, so multiple users can set their own individual preferences. Like many Mac OS X application preferences files, this is an XML file that can be read in TextEdit or the PropertyListEditor utility installed using the Developer Tools CD; don't change it unless you know what you're doing. The AppleScript folder is found in the Applications folder at the root level of your Mac OS X disk. In addition to Script Editor, it contains the Script Runner application and a folder of Example Scripts for use with Script Runner (you must first copy them into the Scripts folder, described next). A Scripts folder is found in the LIbrary folder in each user's Home folder. This is the folder that holds any compiled scripts that are to be made available in the Script Runner button, whose use is described in detail below. Each user may install a unique set of scripts in his or her Scripts folder. The Scripts folder comes empty, but any scripts can be installed in it. For example, a number of useful scripts, arranged into subfolders such as Basics, Finder Scripts, and Script Editor Scripts, can be copied into it from the Example Scripts folder in the AppleScript folder described above. If you install them in your user domain, it is best to copy them rather than move them, so that additional users of your machine can still obtain copies from the Example Scripts folder (they won't have access to your domain). Alternatively, create a new Scripts folder in the main Library folder in the local domain and drag the Example Scripts into it; they will then appear in all users' Script Runner menus. The names of some of these Example Scripts begin with About; they can be run like any other script and will provide brief explanations of the contents of the folder in which they appear. Holding the Command key down while opening the Script Runner menu lets you open a script for editing in its native editor. One of the scripts in the URLs folder takes you to The AppleScript Sourcebook. Note that, because all scripts in the Scripts folder are made available in the Script Runner menu, this is not a good place to put script libraries or other scripts that are not appropriate for use in a menu; for libraries, try the Scripting Additions or Application Support folders, instead.    There are useful scripts located in other folders. A large number of ColorSync scripts are in the Scripts folder of the ColorSync folder in the Library folder in the local domain. Several very complex and interesting Image Capture scripts are in the Scripts folder of the Image Capture folder in the local domain's Library folder; among other things, these scripts showcase how much can be done with the Finder using AppleScript.

A Scripting Additions folder may be found or created in the Library folder in any user's Home folder, so that individual users may install different sets of scripting additions for their own use. A Scripting Additions folder may also be found or created in the Library folder at the root level of the Mac OS X disk, where scripting additions can be installed and made available to all users of the machine, or in the Library folder at the root level of the Network, where they are available to all users on the network. (Making network scripting additions work is reportedly a task for experts administering a Mac OS X Server machine, or masochists using the NetInfo Manager application installed on a normal Mac OS X machine.) Finally, a Scripting Additions folder exists in the Library subfolder of the System folder, unchangeable by users, where the following Apple scripting additions are installed as part of a standard Mac OS X installation: the ColorSyncScripting 3.1 application, the StandardAdditions.osax 1.6 scripting addition, and the URL Access Scripting 1.0 (v3) application. These scripting additions perform the same basic function as the scripting additions or applications with similar names installed in the Mac OS 9.1 Scripting Additions folder, but they are different kinds of files and are not interchangeable. At this stage, most existing third-party scripting additions will not work in Mac OS X and must therefore continue to reside in the Scripting Additions folder in the System Folder of the Classic environment, for use only with the Classic environment. As time goes by, new scripting additions will become available that run only in Mac OS X, as well as some that will run in both environments. In the case of scripting additions that run in both environments, it is necessary to place a copy both in the Classic environment's Scripting Additions folder and in appropriate Mac OS X Scripting Additions folders, even if the scripting addition comes in a single file.

The AppleScript extension, known in Mac OS X as AppleScript.component 1.6, is in the Components folder of the LIbrary subfolder of the System folder. OSAApplet.component 1.6 is here, as well. The Mac OS X AppleScript.component file performs the same basic function as the AppleScript 1.6 system extension that is installed in the Mac OS 9.1 Extensions folder, but they are different kinds of files and are not interchangeable.

Each user's AppleScript Preferences are in the com.apple.applescript.plist file of the Preferences folder in the Library folder of his or her Home folder, since each user may set different preferences. This preferences file comes into existence only after the user has set AppleScript formatting preferences using Script Editor or another editor.

The scriptable Finder is located in the CoreServices folder in the Library subfolder of the System folder. Interestingly, there are two Finders here, one an application whose version is given as Mac OS X Finder, and another, a 4K Classic Application, whose version is given as Mac OS X Fake Finder 1.0. You will also find the scriptable Help Viewer 1.7 application here.

Of interest mostly to developers, the header files for many parts of the system are in the Frameworks folder in the Library subfolder of the System folder, even if you do not install the Developer Tools. These include AppKitScripting.framework and Scripting.framework. See Information for Developers for more AppleScript information of interest to developers.



#3 2001-09-25 09:23:12 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)


Many AppleScript bugs have been fixed, as is usual with new releases of the Mac OS. These are the fixes most likely to benefit you (fixes to a few very rare issues are omitted from this list).

The Read/Write commands in Standard Additions 1.5.5 had disabling problems, including when writing to lists and reading files using delimiters. Almost all of these are fixed in Standard Additions 1.6.

They correctly read back binary data that was originally written As List or As Record and contained nested lists or records.
They correctly read back successive lists or records.
They read the remaining bytes in a file when requested to read more bytes than exist in the rest of the file, without generating an error. The next Read will generate a proper end of file error.
They work correctly on files larger than 2 Gigabytes, using double integers rather than integers as the type of all parameters and results relating to file position. You will normally see these as real numbers.

The Read/Write commands also have what might better be called enhanced behaviors than bugs, outlined by Chris Nebel:

They allow reading a file with the Using Delimiter option set to a list of any number of single-character delimiter strings, rather than only one or two delimiter strings, as before (although the comment in the dictionary still refers to the two-character limit). Apple's Chris Nebel pointed out on the AppleScript-Users mailing list that single-character means single-byte, so that two-byte charcters in some language systems cannot be used as delimiters, and that additional characters in any one delimiter string beyond the first character will be ignored.
They allow omission of the As parameter from Using Delimiter, in which case As Text will be assumed. This is also true if you use Before or Until. Formerly, you always had to use the As parameter with Using Delimiter.
They allow the use of positioning parameters such as From and To when reading a file As List, unless it is being read as a binary list without delimiters (where the list data itself specifies how much to read). However, a bug causes problems when reading a text file As List. Formerly, you could not use positioning parameters with As List, and the command always read from the current position to the end of the file.

See New Bugs in Mac OS X for a discussion of two new bugs in the Read/Write commands.

Cancelling the Where is application dialog when compiling or loading a script no longer causes it to reappear repeatedly, as it did in AppleScript 1.4.3 and 1.5.5.

A running script now responds to more than one successive incoming event. It reportedly did not in AppleScript 1.4.3 and 1.5.5.

A bug has been fixed that could in rare cases cause an applet in AppleScript 1.4.3 and later to fail to retain the value of a variable or to think the variable is undefined, especially with applets using global variables and idle handlers and making heavy use of memory after running for a long time.

The statement 'strings of <string>' now returns error number -1728, can't get every string of <string>, instead of returning an empty list as it always has.

The statement 'text of <string>' now returns the string itself, instead of returning an empty list as it always has.

The statement 'some <type> of <record>' now returns error number -1728, can't get some <type> of <record>, instead of returning the entire record as it always has.

A null string will appear in the Results window and Event Log as a null character between quotes (it is visible in some fonts), as it did in AppleScript 1.0 through 1.1.2, and it will copy and paste in correct, compilable form. In AppleScript 1.3 through 1.5.5 it appeared in various other forms and in some cases would not compile after being pasted into a script.

A script compiled to target an application in the Mac OS X environment can be opened in the Classic environment. This was not true in Mac OS X Public Beta in the case of applications that have counterparts in both environments.

A script targeting a bundled (or packaged) application in the Mac OS X environment, such as Mail, will successfully control that application when run in the Classic environment.

AppleScript 1.6 will now load bundled (or packaged) scripting additions. To run in Classic or on Mac OS 9.1, the bundle must include a top-level alias file that points to the Mac OS 9 (non-Carbonized) scripting addition file contained in the bundle (or package).

The Mac OS X version of Script Editor 1.6 can now read the dictionaries of bundled (or packaged) applications. The Classic version of Script Editor 1.6 still cannot.

In Mac OS 9.1, none of the commands in Standard Additions worked if the new Security items in the Extensions folder were disabled. This bug bit many users who routinely disabled the Security items because they did not use the Keychain and felt secure enough without the extensions. In both the Classic environment of Mac OS X and the new 1.6 release of Standard Additions for Mac OS 9.1, only the Mount Volume command in Standard Additions requires the Security items.

Old-style control panels, like the newer control panel applications, can now be launched by directing a Tell command at them (even if they are not scriptable).

The many problems with Unicode text manipulation in Mac OS 9.1 are, for the most part, fixed in AppleScript 1.6. Any operation (well, almost any) that can be performed on a string value can be performed on a Unicode text value, such as coercion to and from string and styled text, coercion to and from numeric values, the Length property, the Count command, string concatenation, the Character, Word and Paragraph elements for use with the indexed, special index and range keyforms, and magnitude and equality comparisons.

The Random Number command in Standard Additions has been improved to make the generated numbers more evenly distributed and less predictable. Chris Nebel has indicated that there are nevertheless problems in 1.5.5 and 1.6 with random integers coming out with different frequencies. The endpoints (in this case, 1 and 56) tend to turn up out of proportion to the others. 9/22/01



#4 2001-09-25 09:29:27 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)

Running Mac OS X Classic for the first time places CarbonLib 1.2 in the Classic environment's Extensions folder, if an older version is found (the Mac OS 9.1 disk that comes with Mac OS X installs CarbonLib 1.1.1). CarbonLib 1.2 is not the finished version of CarbonLib; CarbonLib 1.2.5 was already already available separately from Apple, and CarbonLib 1.3.1 became available shortly later. Each new version of CarbonLib has brought many bug fixes and new features, and this trend can be expected to continue. It is unclear what changes affect AppleScript and the Script Editor, but there are probably some that do, and updating to the latest version is therefore highly recommended. Mac OS 9.2.1 includes CarbonLib 1.4, and CarbonLib 1.4 can be downloaded separately for installation on earlier versions of the Mac OS going back to and including Mac OS 8.6. 9/22/01

Apple has published Tech Info Library article 106302, Mac OS 9.1: Conflict Between CarbonLib 1.3.1 and AppleScript. It describes a conflict between AppleScript and CarbonLib 1.3.1 in Mac OS 9.1 that can freeze the computer, with suggested solutions. The solution now, of course, is to upgrade to Mac OS 9.2.1, or at least to install CarbonLib 1.4. 9/22/01

I experienced difficulty seeing the left pane of the dictionary window in Script Editor 1.6 after enlarging it and choosing Set Default Window Size from the File menu. Resizing it, or even just clicking on the resize control, seems to cure the problem for a particular dictionary.

The Read/Write commands of Standard Additions exhibit two known new bugs:

Using the As List and Using Delimiter parameters in the same command doesn't work right, incorrectly embedding each list item in a sublist. In this case, use As Text, instead.
Using the As <Type> parameter with Before or Until without a Using Delimiter parameter will generate an error or return garbage. Instead, read the file without the As parameter and coerce the result afterwards.

Both of these bugs will be fixed in the next release.

Magnitude comparisons with Unicode text do not honor the Considering Case condition correctly.

Marco Piovanelli reported that AppleScript 1.6 has broken the ability to coerce Unicode text to normal strings. A simple coercion like '<<data utxt0041>> as string' generates a runtime error, in both the Classic and Mac OS X environments. I discovered that, for an easy workaround, you can use '<<data utxt0041>> as international text'. Apple's Chris Espinosa later wrote, the utxt -> **** handler is broken for typeChar, and has been since 1.5.5.  The good news is that typeStyledText works, so I guess a workaround for now would be to coerce the unicode to typeStyledText, then coerce the result to typeChar. 9/22/01

Steven Angier reported (and this was confirmed by Apple's Chris Nebel) that there is a crashing bug in the Standard Additions choose file name command under Mac OS 10.0.4. Supplying an empty default name string will crash the current script editor or script application when the command is executed. 9/25/01

Chris Espinosa of Apple has remarked upon a subtle point of Finder usage that might be seen as a bug. When the Finder returns an empty value collective Get Data operation (anything with a plural anywhere in the direct object, such as your 'name of folders of myFolder'), it doesn't return an empty list, it returns an empty *record*.  Which looks and prints and smells like an empty list, and compares correctly to an empty list, but can't do list-like things, like having its end set. ['if theClients = {} then set theClients to {}'] is unfortunately the correct workaround, as there's no way to specify an empty record in AppleScript itself. 9/22/01

Apple's Chris Nebel confirmed that the Finder in Mac OS X 10.0 doesn't understand file <path> references. However, alias references and long-hand Finder object specifiers both work fine. 9/22/01

Chris Nebel confirmed that [c]ounting paragraphs and getting individual ones (e.g. paragraph 42 of ...) does the right thing with cr, lf, or crlf line endings, but getting a range of paragraphs (e.g. paragraphs of ..., paragraphs 2 thru 17 of ...) messes up with crlf line endings. In the latter case, the effect is to see a spurious empty paragraph between every real paragraph in the returned result. 9/22/01

AppleScript 1.6 introduces a known problem with using the mount volume command to mount volumes hosted on certain kinds of servers, especially Windows 2000 machines. This problem will be addressed in a future version of AppleScript. 9/22/01



#5 2006-06-23 09:36:31 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)

If you are a developer, you will want to install the Mac OS X Developer Tools that ship with every copy of Mac OS X 10.0. These install a large number of tools and documents of interest almost exclusively to developers, including some relating to AppleScript. The AppleScript features of Developer Tools are described briefly here.

After the Developer Tools are installed, your Mac OS X startup volume contains a new folder, Developer. The Developer folder contains many subfolders.

The Applications subfolder includes, in the Extras folder, two scriptable applications, Sketch (a bundled Cocoa drawing application) and WorldText 1.1. As noted above, WorldText is scriptable almost by accident as a result of the development environment used to create it. Two other applications installed by Developer Tools are scriptable, PEFViewer (another of those accidentally scriptable applications) and Interface Builder. Interface Builder is the Cocoa visual user interface builder application; it is quite interesting to find that it is scriptable.

The Documents subfolder contains a dozen folders with documentation for various aspects of Mac OS X development. The documentation remains a mixed bag of old documents, revised documents and new documents, reflecting the perfectly understandable priority that Apple attached to getting the product out the door on time. We will not attempt to list everything related to AppleScript that can be found here. Examples include the interapplicationcomm folder in the Carbon folder, which includes the old AppleScript 1.3.4 Language Guide in HTML format and other material of use in Carbon-based AppleScript development, and the ProgrammingTopics and TasksAndConcepts folders in the Cocoa folder and other matter of use in Cocoa-based AppleScript development. The most interesting item for scripters may be the ReleaseNotes folder, which includes, among other things, a small file called AppleScript.html, which contains some Release Notes for AppleScript 1.6 in the Mac OS X environment. This contains pointers to other AppleScript developer information, a summary of how to write scripting additions for Mac OS X (including some information which I don't believe has been systematically made available previously), and a short list of known bugs in AppleScript 1.6.

The Examples subfolder includes source code for some scriptable applications, including the scriptable TextEdit and Sketch applications built with the Cocoa frameworks.

In the months since the release of Mac OS X 10.0, new documentation for developers interested in AppleScript has trickled out of Apple, including the following:

Technical Q&A QA1070, Loading Scripting Additions without initializing AppleScript in Mac OS X.

Revised Technical Note TN1164, Native Scripting Additions. It now includes additional information needed by developers to write native scripting additions for Mac OS X information that was previously available only to those who knew whom to ask or watched the mailing lists closely.

Technical Note TN2022, The Death of typeFSSpec: moving along to typeFileURL. It explains for Mac OS X developers how to pass references to files that have not yet been created. This issue has had an impact on developers of recordable Mac OS X applications.

Technical Q&A QA1018, Using AppleScript to send an email with an attachment. This developer Q&A item contains the text of a complete AppleScript for using the Mac OS X Mail program to allow the user to choose a text file that will be attached to an outgoing e-mail message.



#6 2001-09-25 08:56:25 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)


Many third-party applications are being upgraded to run natively in Mac OS X, including applications that are important to the AppleScript community either because they are scriptable or because they facilitate writing of scripts or development of scriptable applications. Although most of these will not be available immediately, many will appear with or very shortly after the release of Mac OS X. Some originated in the classic Macintosh, while others trace their ancestry to NextStep, OpenStep, Rhapsody, and beta versions of Mac OS X. This report will not attempt to list all of them because, happily, there are too many. Those listed here may be considered especially important to scripters.

Script Editors and Environments

Apple's Script Editor 1.6 is a functional but spare script editor with minimal debugging features that is installed as part of Mac OS X. In appearance and capability it is virtually identical to the Script Editor that has been part of the Mac OS since 1993. It was the first Carbonized application from Apple. You will find versions of it in both the Mac OS X and the Classic environments.
Late Night Software's Script Debugger, a more capable script editor and debugger, is being migrated to Mac OS X and will appear as Script Debugger 3.0 about the time Mac OS X 10.1 appears in September 2001. This is a high-end script editor and debugger that has many powerful features not available in Apple's own Script Editor.
Late Night Software has also released XML Tools, a scripting addition to parse and generate XML data using AppleScript that runs both in the Mac OS X and the Classic environments as well as older versions of the system.
Late Night Software's JavaScript OSA is an OSA component that allows the use of JavaScript as an alternative to AppleScript for OSA scripting in both the Mac OS X and Classic environments as well as older versions of the system.

Scripting Additions
Additional Mac OS X scripting additions are appearing. Some are described in the Scripting Additions section of The AppleScript Sourcebook's Links chapter. A more complete list is available at osaxen.com hosted at MacScripter.net. 9/22/01

Scriptable Applications
Additional or revised Mac OS X applications with AppleScript support are appearing at a rapid pace. See the Scriptable Applications section of The AppleScript Sourcebook's Links chapter for details. 9/22/01



#7 2001-09-25 08:58:47 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)

Several new AppleScript features, changes to existing features, and bug fixes are introduced in Mac OS X. Many of these apply across the board to the Mac OS X and Classic environments and to Mac OS 9.1, as well. Several scripting additions and other scriptable items that are installed as part of Mac OS 9.1 have not yet been included in the Mac OS X environment, however, although many soon will be added. On the flip side of the coin, there are a few new AppleScript-related items that are available only in the Mac OS X environment.

New Features

The dictionary in Finder 10.0 contains a number of new features, but for the time being, the Finder's dictionary is explicitly described as provisional in both environments of Mac OS X. Some dictionary items are not yet hooked up and others do not work correctly. These gaps should be filled shortly, perhaps by the time of the promised summer update to Mac OS X. See The Scriptable Finder for more information.

The Standard Additions scripting addition is updated to version 1.6 and has changed in some respects in Mac OS X. Most importantly, it defines a new System Attribute command in the Mac OS X environment, replacing the Computer command formerly implemented in the Finder's dictionary. Apart from the name change and the fact that you no longer need to call it in a Finder Tell block, the System Attribute command's parameters and usage are identical. In fact, when you compile a script in the Mac OS X environment that contains the Computer command, whether in a Finder Tell block or on its own, it automatically changes to a System Attribute command. Scripts compiled in either the Mac OS X environment or Mac OS 9.1 or earlier using the name for the command that is available in that version of the system will run under the other without recompiling, provided that the Finder Tell block is included for scripts running in Mac OS 9.1 or earlier. You are left to remove the 'tell application Finder' wrapper yourself from scripts originally written for Mac OS 9.1 or earlier, if you wish to, although if left in place it is harmless when the script runs under Mac OS X and will provide backward compatibility with the old Computer command when your script runs under Mac OS 9.1 or earlier. (There is one fly in the ointment, however. The new System Attribute command is unique to the Mac OS X environment; it is not present in the Mac OS 9.1 and Classic versions of Standard Additions 1.6. This will lead to serious problems for some older scripts, because the Finder's Computer command is also unavailable in the Classic environment. See Testing Whether AppleScript 1.6 is Installed for more information about this and another bug associated with the new System Attribute command and the elimination of the Finder's Computer command.) For other amendments to the Standard Additions dictionary, see Dictionary Changes.

Many new features are functional or available only in the Mac OS X environment, such as new constants for the Path To command in Standard Additions, and new scriptable applications. See Where AppleScript Items Are Located and AppleScript Tools, Scripting Additions, and Scriptable Applications for information about them.


There are a number of changes to the scripting experience in Mac OS X, in addition to the new features described above and the limitations described below.

Users of Mac OS X Public Beta will notice that the Finder is now once again called the Finder, not Desktop (or Desktop.app) as it was in Public Beta. The Finder's dictionary contains a few changes since Mac OS 9.1, both in the Classic and the Mac OS X environments, as dicussed below in The Scriptable Finder.

Users of Mac OS X Public Beta will be pleased to know that recording is now available using Script Editor, for applications that support recording.

Instead of using the classic Mac OS Startup Items folder to launch an AppleScript at boot time, place the script application anywhere you like, open the Login pane in System Preferences, click the Login Items tab, and assign the script to run at startup time. I haven't found a way to run a script at restart, shutdown or log out time, however. The Execution State property of the Finder's Application class, introduced in Mac OS 9.1, is gone in Mac OS X, so you can't run a stay-open applet to check the execution state periodically.

To write a script for use in Mac OS X that uses terms from a Classic environment scripting addition, a topic in the Help Center explains that you have to make use of the Using Terms From command. According to this topic, you enclose the scripting addition commands in a Using Terms From block to allow them to compile using the Classic scripting addition's terminology, and enclose the Using Terms From block in a Tell block directed at a scriptable Classic environment application. This will force the scripting addition command to execute in Classic, because scripting additions always run in the same environment (Classic or Mac OS X) in which the application addressed in the enclosing Tell block is running. (If you have scripting additions with both Classic and Mac OS X counterparts that behave differently in the two environments, you could use this technique to force the script to use one or the other counterpart.) Many, including me, were unable to make this recommended technique work until two alternative solutions appeared on the AppleScript mailing lists:

In two steps: First, put the scripting addition commands in a Using Terms From block, addressing an alias to the scripting addition using its path in the classic Mac OS Scripting Additions folder, and compile. Then remove the Using Terms From wrapper from your script (leaving the innards of the block in place, with their raw event codes) and replace it with a Tell Application <name of any classic aplication> wrapper, and recompile.
In one step: Put your scripting addition statements in a Using Terms From block, addressing an alias to the scripting addition using its path in the classic Mac OS Scripting Additions folder. Wrap the Using Terms From block in a Tell Application block, using a variable containing the name of the application instead of the name itself. Before the Tell Application block, insert a script command to launch any classic Mac OS application using its path as a hard-coded string (since the Path To command won't let you find the classic Scripting Additions folder when running in Mac OS X). Compile. 9/22/01

If you examine the scripts that come with Mac OS X, you will notice that many of them carry a .scpt suffix, or file extension, in their names. AppleScript and Script Editor work both with these scripts (which have their dictionaries in their data fork, instead of in a resource fork) and with existing scripts that lack the file extension. You do not have to add the file extension to existing scripts, nor to scripts you create using Script Editor in Mac OS X. In general, I am told that Script Editor will honor .scpt for compiled script files, .applescript for uncompiled text, and .osax and .asdictionary for terminology. 9/22/01

The Dialect pop-up menu has been removed from Script Editor 1.6, since dialects other than English were removed in AppleScript 1.3.

One thing that has not changed is the format of file paths in AppleScript: they are still delimited by colons. Apple's new AppleScript 10.0 Overview gives an example handler to convert an AppleScript path to a path using the Mac OS X-standard forward slash delimiter.

The Mac OS X environment currently lacks many of the scripting additions and other scriptable items on which scripters have relied in the past. Although this will limit the tasks that can be performed by AppleScript for now, it is expected that many of these gaps will be filled in the promised summer release of the Mac OS X update, if not sooner. The items that are missing, or whose scriptability is missing, for the time being from the Mac OS X environment are listed below, followed by discussion of other limitations on AppleScript in Mac OS X.

Scripting additions: AirPort Scripting (introduced very recently with the AirPort 1.3 upgrade for Mac OS 9.1), Desktop Printer Manager (but see Mac OS X Print Center), FileSharing Commands, Keyboard Addition, Keychain Scripting, MonitorDepth (but see QuickTime Player), Network Setup Scripting, Sound Scripting, and Speech Listener.
System extensions: Application Switcher, Folder Actions, and FontSync Extension.
Control panel applications: Appearance, Apple Data Detectors, Apple Menu Options, File Exchange, File Sharing, FontSync, Location Manager, Memory, Mouse, Startup Disk, USB Printer Sharing, and Web Sharing. Two of these, USB Printer Sharing and Web Sharing, were minimally scriptable in Mac OS 9.1 only as an accidental artifact of the development system that was used to create them.
Applications: Apple Applet Runner, Apple Verifier, Apple Video Player, Disk Copy, Disk First Aid, and WorldText (but WorldText is available on the Mac OS X Developer Tools CD, and Mac OS X includes its own scriptable TextEdit application). One of these, WorldText, was minimally scriptable in Mac OS 9.1 only as an accidental artifact of the development system that was used to create it.

Limitations on AppleScript user interaction commands, such as Display Dialog, are discussed extensively, with workaround strategies, in Apple's new AppleScript 10.0 Overview. This issue requires care and testing of your scripts that employ user interaction commands, but the change in scripting style required to deal with this limitation is not difficult to master. Basically, AppleScript-generated dialogs and windows will appear only in applications that are able to execute scripts, such as Script Runner and AppleScript applets, or in the application that is running the script, such as Script Editor. In the latter case, telling the application target of the Tell block to activate will not bring the application that is running the script to the foreground, and, unless you employ a workaround, the user may therefore have to bring it to the foreground manually to see the dialog or window. Rather than repeat the workarounds here, I urge you to read Apple's discussion. For example, you can enclose user interaction commands in a Tell Me block, or move them to a separate handler that executes outside of the Tell Application block. The AppleScript 10.0 Overview gives many other examples. Users of older versions of Leonard Rosenthol's OSA Menu will find some of this familiar. Apple expects to address this limitation in a future release.

In Mac OS X, traditional Macintosh resource-based file types are optional. Some documents do not have such resources, but depend instead on file name extensions like .jpg and .tif. This will at first be very uncomfortable to Mac users, who tend to scorn file extensions as an MS-DOS antique, but we will have to get used to them. Indeed, Apple is encouraging the use of file extensions because they confer compatibility benefits in the Internet context and elsewhere. This has an important impact on scripters. When using the Info For command to check a file's type, you must hereafter also check for a file extension. The AppleScript 10.0 Overview gives examples of how to parse a file extension. When using the Choose File command, you should follow a similar strategy.

Although scripts running in either environment of Mac OS X can control scriptable applications running in the other environment, the Classic Script Editor cannot see the dictionaries of Mac OS X applications, such as Mail, that are bundles, because it thinks they are folders. Other Mac OS X applications, such as Carbonized applications based on the traditional single-file, dual-fork application model, are visible to the Classic Script Editor.

Some items that are scriptable in Mac OS X are not available at all in the Classic environment, much less scriptable there. For example, many Classic control panels are not available because the Classic environment uses Mac OS X settings. Since the Mac OS X System Preferences application is not scriptable in this release, there are therefore some things you can't do with AppleScript even in the Classic environment, which you could do in Mac OS 9.1 and earlier. For example, the Network Setup Scripting scripting addition application will not work in the Classic environment. In terms of sheer numbers, this limitation will probably have the greatest impact on existing scripts.

In Mac OS X, the Apple Event Manager does not currently support sending events to remote machines. Issues with the user interface and security models have not yet been resolved, and Program Linking is not supported. In addition to being unable to specify a remote application in a Tell block, you cannot open dictionaries of remote applications or select remote applications when choosing an application.

AppleScript does not support preemptive threads under Mac OS X (and never did under the classic Mac OS).

Mac OS X does not currently come with a scheduling application equivalent to the iDo Script Scheduler utility that ships with Mac OS 9.1. You can, however, explore the capabilities of the Unix cron command, which is included with Mac OS X; type man cron in the Terminal application for instructions. Since the release of Mac OS X, at least two utilities have appeared that do perform a scheduling function: CronniX 1.2, an application from Sven Schmidt that puts a user interface on the cron command (and thus has nothing to do explicitly with AppleScript, although it can be used to launch applets on a schedule), and Script Timer 1.1X, an application from Donald Hall that launches AppleScript and other OSA scripts according to any schedule. 7/13/01

Apple Data Detectors are not included in Mac OS X, but it is likely that the Mac OS X Services feature will eventually fill a similar role.

Folder actions are not implemented in the current release of Mac OS X, although the new Standard Additions 1.6 still includes the folder actions commands. Expect to see them in a future release.

When using the Classic Script Editor to open or compile a script, it may fail at first because some applications have to launch in order to disclose their dictionaries. Give it a little more time, then try again.

Volumes configured as UFS or NFS volumes will not work correctly with the Info For command in Standard Additions. Most users are advised to format their disks as HFS Plus, or Mac OS Extended, volumes, in any event, so this will not affect many scripters.

The Path To and Info For commands from Standard Additions may return unexpected results in some cases. Some Mac OS X applications are not traditional application files, but bundles (just as a few Mac OS 9 and later classic applications are packages). A bundle (or package) is a folder containing a number of other items, including subfolders and files, but the Finder and other savvy applications display them as if they were files. The Path To command, when addressed to such an application, will usually return the name of the application with the .app file extension. The Info For command will usually return true for the Folder property, and the File Type, File Creator and some other properties will not be available. Hopefully, these issues will be resolved in a future release of Mac OS X.


The release of Mac OS 9.2.1 on August 21, 2001 followed a more tortuous path than usual. Initially, the original edition of Mac OS 9.2, having a code name of Moonlight, was completed in the summer of 2001 but was never shipped. Later, the summer 2001 iMacs and perhaps some other new machines shipped with an updated Mac OS 9.2, codenamed Starlight. Finally, on August 21, Mac OS 9.2.1 was released to the public, codenamed Limelight. Or so the rumors would have it the code names are certainly evocative.

Mac OS 9.2.1 was described as a bug-fix release, intended to help bring the classic Mac OS to its end of life in good shape for long term use on older machines and to provide better compatibility with the Classic environment of Mac OS X. Nevertheless, there are a few new AppleScript-related features included in it, even though AppleScript itself and the Script Editor remain at version 1.6.

The Keychain Scripting faceless background application is at version 2.4, up from 2.2. Its dictionary includes a new Run command as the flip side of its existing Quit command. The Creator Code property of class Key has been changed to Creator Type to bring it into conformity with common usage in other contexts. Finally, class AppleShare Key has a new property, Address, which is described as the DNS host name or IP address for servers on a TCP/IP network.

The Network Setup Scripting faceless background application is at version 1.3.1, up from 1.2. It includes a new property in the Remote Access Suite, Answers Calls, to turn on or off incoming calls to Remote Access server if installed and not locked.

The Sound Scripting faceless background application is at version 8.5.6, up from 8.5.4. The Set command has been removed, consistently with the overhaul of AppleScript terminology some time ago. However, this item has not been given a new Run command, as was Keychain Scripting. The former Settings class is now class Application, and several properties have been renamed for the sake of clarity: Alert Sound to Current Alert Sound, Sound Input Device to Current Sound Input Device, Sound Input Source to Current Sound Input Source, and Sound Ouput Devices to Current Sound Output Devices.

The FontSync Extension is at version 2.0, up from 1.0, as part of an extensive overhaul of the FontSync technology. The Set and Get commands were removed as part of the ongoing campaign to overhaul AppleScript terminology. The existing Create Font Profile command has two new parameters, Using Font Reference Version and Font Ref Version.

Finally, the following scriptable items were upgraded without changing their dictionaries: Startup Disk, URL Access Scripting, and Folder Actions.

The AppleScript Help module in Apple Help still carries (at least on my computer) a What's New section describing changes in AppleScript 1.5.5.


The HTML-based Apple Help system is alive and well in Mac OS X, and it contains some information relevant to AppleScript. Open Mac Help from the Help menu of almost any Mac OS X application and search for the word AppleScript, or open the Help Center and choose AppleScript Help. You will be invited to go to a section where you can Learn what's new with this release of AppleScript, and to read topics entitled What is AppleScript?, How do I use Script Editor?, and How do I start writing scripts? Ask also about other topics, such as Automating color management tasks and Script Runner. Topics requested in Apple Help under Mac OS X are quite often downloaded from Apple's web site, so the information should always be up to date.

Shortly after the release of AppleScript 1.6, Apple published Tech Info Library article 60835, AppleScript 1.6: What's New and Different from AppleScript 1.5.5. 9/22/01

Apple's AppleScript in Mac OS X overview provides extensive information about new AppleScript features in Mac OS X 10.0, along with some sample scripts and an e-mail address to which you are requested to send feedback (i.e., bug reports and feature requests) specifically related to AppleScript in Mac OS X: OSX_AppleScript_feedback AT apple.com. The documentation is also provided in the form of a downloadable Mac OS X Help Center module called AppleScript 10.0 Overview so that you can have it available at all times when using Mac OS X.



#8 2001-09-25 08:53:02 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)

Mac OS X, rumored to have gone by the development code name of Cheetah, officially went on sale on March 24, 2001, as promised by Steve Jobs at his Keynote Address at Macworld Expo in San Francisco on January 9, 2001. It is officially known as Mac OS X 10.0, according to Apple's Phil Schiller, who is quoted as having said, We used the roman numeral because we thought it would be cool and fun. But officially it's Mac OS X 10.0. The 10.1 release could appear on new machines in the summer. It subsequently received several updates and is currently at version 10.0.4. Rumor has it that the code name for the next major upgrade scheduled for September 2001 is Puma. Rumors also suggest that the next major release after that, 10.2, due in the January 2002 time frame, will be named Jaguar. 9/22/01

AppleScript 1.6 is included in the native Mac OS X environment, where it first saw the light of day on March 24, 2001. Another version perhaps we should call it another edition, since it bears the same version number of AppleScript 1.6 is installed in the Classic compatibility environment the first time you launch a Classic application after starting up in Mac OS X. AppleScript 1.6 for Mac OS 9.1 was also released separately on March 28 as an update for those who are not upgrading to Mac OS X; Apple describes it as being identical to the edition of AppleScript 1.6 found in the Classic environment of Mac OS X. In a March 24 press release, AppleScript Product Manager Sal Soghoian said of AppleScript 1.6:

As with any project of this scope, there's still much to do, but we are excited about the future. We look forward to expanding AppleScript's abilities to incorporate many of the new features integrated into this UNIX-based OS.

When AppleScript 1.6 for Mac OS 9.1 was originally released as a separate updater, Mac OS 9.1 had already been available to the public since January 9, 2001. Mac OS 9.1 had originally included AppleScript 1.5.5 as its scripting environment. See New Features, Changes, and Limitations in AppleScript 1.6, below, for discussion of AppleScript 1.6 as it was initially released. Later, on August 21, 2001, the classic Mac OS was updated to Mac OS 9.2.1, which incorporates AppleScript 1.6. Although Mac OS 9.2.1 therefore does not include a new, previously unavailable version of AppleScript, it does include a number of new and changed AppleScript-related features. These are described in a separate subsection of this report, New AppleScript Features in Mac OS 9.2.1. 9/22/01

This report will focus on AppleScript 1.6 in the native Mac OS X environment, but every effort will be made to flag differences in the scripting experience in the Classic environment. Except as otherwise noted, references in this report to Mac OS X should be understood to refer to the native Mac OS X environment, not the Classic environment. References to Mac OS 9.1 are generally meant to refer to the Classic environment of Mac OS X, although there are many differences between the way AppleScript works in Mac OS 9.1 and Mac OS 9.2.1 as a standalone operating system and the way AppleScript works in Mac OS 9.1 or 9.2.1 as it exists in the Classic environment particularly with respect to Finder scripting and scripting of system settings that are no longer available in Classic through traditional control panels. These differences will also be discussed in this report.

The core of AppleScript 1.6 as it exists in the native Mac OS X environment generally uses the same terminology and offers the same functionality as in the version of AppleScript 1.6 that is installed in the Classic environment or in Mac OS 9.1 or 9.2.1 as a standalone operating system. Scripters familiar with AppleScript 1.5.5 or earlier will find scripting in both environments of Mac OS X eerily familiar. Many scripts from AppleScript 1.5.5 or earlier will run without change both in the native Mac OS X environment and in the Classic environment of Mac OS X, and others will require only minor modifications. Indeed, in the new parallel universes of Mac OS X, a script in one environment can work with data and applications in the other environment. When a script uses commands from scripting additions, you might not even be sure in which environment they are running.

Nonetheless, because there are differences among them, your scripts may well have to test whether they are running under Mac OS 9.1 or 9.2.1 standalone, the Classic environment, or the Mac OS X environment before invoking features that are unique to any of them. See Testing Whether AppleScript 1.6 is Installed for a handler you can use for this purpose.

A large number of the ancillary features of AppleScript that appear in Mac OS 9.1 or 9.2.1 or in the Classic environment are not yet available in version 10.0 of the native Mac OS X environment, although it is expected that many of these will be reinstated in subsequent releases. Several of Apple's scripting additions that form part of Mac OS 9.1, for example, are not included in Mac OS X, and a number of other items that are scriptable in Mac OS 9.1 are not yet, or not fully, scriptable in Mac OS X. Although the Mac OS X Finder is scriptable, the operational parts of its dictionary are not yet as extensive as in Finder 9.1, and the dictionary contains several warnings that terminology and features may change. Many of these gaps will likely be filled by the time of the promised summer update to Mac OS X, when new Macintosh computers are to begin shipping with Mac OS X installed as their primary operating system.

Like the reports on previous versions of AppleScript, this report is based on information obtained from various sources, including official Apple publications and several AppleScript and Mac OS X mailing lists and news groups, and my own investigations.



#9 2001-09-25 09:19:38 pm

Bill Cheeseman
Registered: 2006-06-29
Posts: 158

Re: AppleScript 1.6 (Mac OS 9.1 and 9.2.1 and OS X 10.0 Cheetah)


This section lists applications and other software from Apple that either works with or facilitates the use of AppleScript in the Mac OS X environment, as well as scriptable applications that are installed with Mac OS X. This may seem like faint praise, but I am pleased to report that all of them work. Given the radically different underpinnings of Mac OS X, it is a remarkable accomlishment. (Note, however, that I have not yet exhaustively tested any of them, and I don't expect all of them to work well.)

First, Mac OS X uses Mac OS 9.1 or newer in the Classic environment, so a machine on which you will install Mac OS X must first contain Mac OS 9.1 or newer that is, if you intend to use the Classic environment; it is not mandatory. To make upgrading easy, the Mac OS X product comes with the standard Mac OS 9.1 installation CD that is available for purchase separately by people who are not upgrading to Mac OS X. If you want to use the Classic environment with Mac OS X and you haven't already upgraded to Mac OS 9.1, you must do so before you install Mac OS X. This will, of course, upgrade all AppleScript components to their Mac OS 9.1 versions. Note that recent Mac OS 9.1 installation CDs contain newer versions of some items, compared to the versions that were available with the initial release of Mac OS 9.1 at Macworld Expo in early January 2001. I assume that the Mac OS 9.1 CD that comes with Mac OS X is newer, so you may want to use it to update all of your computers to the latest version of Mac OS 9.1, whether you will install Mac OS X on them or not. The Mac OS 9.1 CD that comes with the Mac OS X product reportedly will not boot on the newest machines, like the Powerbook G4. These machines come with Mac OS 9.1 preinstalled, but if you need to reinstall Mac OS 9.1 on one of them, use the Mac OS 9.1 installation CD that came with the machine (version 1.2 came with my new machines).

Installing Mac OS X does not immediately install any new items into your Mac OS 9.1 system. The first time you launch a Classic application after installing Mac OS X, however, you will be asked to permit some Mac OS 9.1 items to be updated and some new items to be installed for use in the Classic environment. Apple assures you that your system will still work properly when you boot directly into Mac OS 9.1 after these changes have been made. Updated items for Mac OS 9.1 in the Classic environment include the new AppleScript 1.6 system extension, the new Standard Additions 1.6 scripting addition, and the new Script Editor 1.6. Although the Finder remains at version 9.1.1, be forewarned that its dictionary looks different when examined within the Classic environment than it does when you have booted directly into Mac OS 9.1. The new features of these Classic items are described in several places in this report, including Dictionary Changes.

Mac OS X installs the AppleScript tools and scriptable applications listed below for use in the Mac OS X environment, in addition to the items mentioned in Where AppleScript Items are Located. In considering the dictionaries of the scriptable software in this list, it is easy to nitpick about signs that some of them were rushed to release without review by experienced AppleScripters, and it is easy to complain about the absence of usage examples or instructions for most of them. Restraint is called for, however. We should be thankful that AppleScript has progressed as far as it has in this first official release of Mac OS X.

We can live for now, for example, with dictionaries whose terminology departs from official AppleScript suites (for example, in Mail and TextEdit, two Cocoa applications, there are several window properties beginning with is, such as Is Zoomed instead of Zoomed, leading to awkward statements like 'if window 1 is is zoomed'). And we can live with commands in a Required Suite, although the Required Suite was officially discontinued and melded with the Standard Suite some time ago (the Close command appears both in the Required Suite and in the Standard Suite in Print Center). And with dictionaries defining terms that don't parse according to plain English usage, in contravention of one of AppleScript's principal goals (the Pref command in Apple System Profiler leads to the vaguely obscene locution, 'tell application Apple System Profiler to pref'). And with terminology that uses initial caps contrary to AppleScript convention (Show Queue and all of the other commands and parameters in Print Center use initial caps).

When examining an AppleScript dictionary in Script Editor, I have occasionally experienced difficulty seeing the left pane, where the scripting suites and their terminology are listed. This happened after I enlarged a dictionary window and chose Set Default Window Size from the File menu. If you encounter this problem, it is easily cured by resizing the window again until the left pane becomes visible; often, simply clicking on the window's resizing widget is enough.

Installed Software

Script Runner application
Script Runner 1.0 is a Mac OS X-only application, sporting a funky icon of a rocketship with the familiar AppleScript symbol emblazoned on its side. It enables you to organize a collection of compiled scripts and to run them. It does not have a window of its own, nor a menu in the menu bar, and it does not appear in the Dock. It is instead a small, floating button that can be moved around on the desktop. The button always remains in front of application windows, so it provides a convenient system-wide means of running scripts at any time. You may want to stash it away in a little-used corner of the screen, since it can be hard to spot on a busy patchwork of application windows. Its initial position at startup is quite annoying: near the upper left corner of the screen, obscuring the main window of just about every application you launch, and it does not remember where you put it the next time you start up your computer.

Clicking on the Script Runner button brings up a hierarchical menu listing all of the scripts in the Scripts folders and their subfolders located in the several domains, as well as a command to open the user's Scripts folder and a Help command. A script can be run by choosing it from this menu, and it can be opened for editing in its native editor by holding down the Command key while opening the menu. When the Scripts folder is open, a script can be dragged in and out of it or placed in a subfolder using the Finder, and the script will appear or disappear from the Script Runner menu or a submenu the next time Script Runner is launched.

Script Runner adds a new dimension to the use of compiled scripts, although it will be very familiar to users of Leonard Rosenthol's OSA Menu for the classic Mac OS. In a bare-bones installation of Mac OS 9.1 and earlier, compiled scripts, unlike script applications, could not be run independently but only within a script editor. To run a script independently, it had to be saved as a script application or applet, and launching one of these entailed the slight delay associated with the launching of any application. For the last few years, Apple's Mac OS installation CDs have included an optional lite version of OSA Menu, which enabled compiled scripts to be quickly and conveniently run from a menu at the right end of the menu bar without launching an application. A number of other third-party launcher palettes, Apple Menu enhancers, and control strip modules provide similar features. For a while, OSA Menu even included an application called Script Runner that worked something like the new Script Runner in Mac OS X. Scripters will find Script Runner to be an essential part of their Mac OS X experience.

Out of the box, there are no scripts in the Mac OS X Scripts folder in the user domain, and there is no Scripts folder in the System or local domains. However, a number of useful scripts are included in an Example Scripts folder in the AppleScript folder, and all of them work well with Script Runner. If you are a heavy AppleScript user, one of your first Mac OS X setup tasks should be to copy the entire contents of the Example Scripts folder into your personal Scripts folder or the main Scripts folder for use with Script Runner. (You will have to quit Script Runner and relaunch it to make the newly-added scripts appear in the menu.) Be sure to make copies of them if you install them in your personal Scripts folder, because removing them from the Example Scripts folder would make them unavailable for installation by any other users of your machine who don't have access to your user domain.

Script Runner is not automatically launched when you boot up under Mac OS X. To avoid having to dig it out of the AppleScript folder and launch it manually every time you start up, add it to the list of Login Items in the Login pane of System Preferences. This will cause it to launch automatically every time you start Mac OS X, as if you had put it in the Startup Items folder in the classic Mac OS. You could instead install it in the Dock and launch it when needed, but launching it at startup via Login Items is more convenient and conserves valuable Dock real estate.

Terminal application
Those familiar with Unix will take delight in knowing that Terminal is included in a standard Mac OS X install, located in the Utilities subfolder of the Applications folder. Terminal provides the Mac OS X command line interface, or CLI, familiar to Unix users.

In addition to all the other amazing things that can be done here, you can run AppleScripts from the command line. We will not go into details in this report. To learn how to do it, launch the Terminal application, type man osascript at the <user>% prompt, and press the Return key. You will be presented with a simple manual describing the osascript command and parameters. It also refers you to manuals for two other AppleScript-related commands, osacompile and osalang. There are limitations to what can be done with the osascript command, but Apple is working on refinements to make it more usable.

The Terminal application itself is not scriptable, although there have been rumors that it will become so in future.

Apple System Profiler application
Apple System Profiler v2.6b21, in the Utilities subfolder of the Applications folder, is the latest version of this frequently-updated utility. Its dictionary is very similar to that of version 2.5.7, found in Mac OS 9.1 and the Classic environment. Changes to the Apple System Profiler dictionary are discussed below.

ColorSyncScripting scripting addition application
The dictionary of ColorSyncScripting 3.1, in the ScriptingAdditions folder in the system-level Library folder, is identical to the dictionary contained in ColorSync Extension 3.0.3 in the Extensions folder of Mac OS 9.1. (Note that the segmented version of Mac OS 9.1 made available for download in early January 2001 did not include the version 3.0.3 ColorSync Extension; this is one reason to upgrade using the Mac OS 9.1 CD that comes with Mac OS X.)

Internet Explorer application
Microsoft's Internet Explorer 5.1b1, in the Applications folder, has a dictionary that is identical to that of Internet Explorer 5.0 in Mac OS 9.1.

Help Viewer application
Help Viewer 1.7, in the CoreServices subfolder of the System-level Library folder, has the same dictionary as Help Viewer 1.6.2 in Mac OS 9.1.

Image Capture Extension application
Image Capture Extension, bearing the tuxedo-and-bow-tie icon usually associated with the various assistants, is in the Carbon.framework bundle, buried deeply in the Frameworks folder of the System-level Library folder; it is best to locate it using Sherlock. To open its dictionary easily, use Script Editor's Open Dictionary command, which gives you an alphabetical list of scriptable applications. It appears to be of limited interest, but an example script using it to rotate images appears in the Scripts subfolder of the Image Capture folder in the main local domain Library folder.

Mail application
Mail 1.0 is a Mac OS X-only e-mail client application, in the Applications folder. It is a bundled (or packaged) Cocoa application whose scripting dictionary is quite extensive. Support for editing mailbox content reportedly is not working in Mac OS X 10.0.

On March 24, 2001, Apple released Mail Import Scripts 1.0.5, three AppleScripts that help you import e-mail messages into Mail from a variety of third-party e-mail clients, including Netscape Communicator 4.x, Eudora 5.x, Outlook Express 5.x, and Microsoft Entourage.

Mail's dictionary is in the form of a couple of so-called plist, or property list, files within the bundle. If you wonder what a plist-based AppleScript dictionary looks like in its raw form, Control-click on the Mail application icon and choose Show Package Contents in the contextual menu. Navigate through the Contents and Resources folders to the English.lproj folder (or the equivalent folder for your preferred language), then drag the Mail.scriptTerminology file onto the TextEdit icon. You will be looking at a plist AppleScript dictionary. (Be careful not to edit it, unless you know exactly what you are doing.)

Print Center application
Print Center 1.0, in the Utilities subfolder of the Applications folder, is where you set up your AppleTalk printers, USB printers, and LPR printers using IP, and monitor their print queues. Its dictionary appears to be a work in progress, including a Test Event command, for example. The descriptions of most of the commands say that they are sent, suggesting that the application sends events to your script, but this may not be so. In the absence of instructions or examples, I have been unable to figure out how to use most of these commands.

QuickTime Player application
The final release of QuickTime Player 5.0 was first introduced as part of Mac OS X. The revised QuickTime Player dictionary (see below) is very complete, expanding even beyond that of QuickTime Player 4.1.3, the latest version available in Mac OS 9.1. It lives in the Applications folder. Reportedly, its scripting abilities may require purchasing the Pro version (your QuickTime Player 3 license won't work, even though it works with QuickTime Player 4; if you purchased a QuickTime Player Pro 4 license, however, it reportedly will work with version 5). A number of AppleScripts for QuickTime Player 5 are available for download.

Sherlock application
Sherlock 3.1, in the Applications folder, replaces Sherlock 3.0.2 from Mac OS 9.1. Their dictionaries are identical.

Standard Additions scripting addition
Standard Additions 1.6, in the ScriptingAdditions folder in the System-level Library folder, is new since Standard Additions 1.5.5 in Mac OS 9.1. There are several important changes in the Standard Additions dictionary.

Stuffit Expander application
StuffIt Expander 6.0.1 is included. The dictionary is identical to that in StuffIt Expander 6.0, the next most recent version released by Aladdin Systems.

A free upgrade to StuffIt Deluxe 6.0.1 is available from Aladdin Systems. The 6.0.1 upgrade is essential for users who want to compress files using StuffIt Deluxe in Mac OS X, because it fixes problems that version 6.0 had with compressing or decompressing some Mac OS X files. It comes with simple instructions to make most elements of StuffIt Deluxe run natively in the Mac OS X environment.

TextEdit application
TextEdit 1.0, in the Applications folder, is another bundled application built with the Cocoa frameworks, like Mail. It appears to be positioned as the standard text processing application for the Mac OS X environment, and it is scriptable with a reasonably useful dictionary. It is certainly a nice replacement for the Classic Mac OS SimpleText application.

URL Access Scripting scripting addition application
URL Access Scripting is version 1.0 (v3) in Mac OS X; the latest version available for Mac OS 9.1 is 2.3. Their dictionaries are identical.

Dictionary Changes
Several changes have been made to scriptable items in Mac OS X that have been updated from their Mac OS 9.1 versions.

Apple System Profiler application
One new command appears in the dictionary of Apple System Profiler v2.6b21: Pref. This command is hardly English-like; would you tell somebody to pref in polite company? This command, according to the dictionary, opens the preferences dialog of the application. The Gathers At Launch and the Preferred Report Contents properties of the Application class and the Report Contents property of the Report class take the new OSX Extensions and Frameworks contants, and there are matching OSX Extension Volumes and Framework Volumes properties. Extensions are Mac OS X kernel extensions with the .kext file extension; my installation has over 200 of them. Frameworks are header files of interest to developers, although they are also essential to the operation of many elements of Mac OS X; my installation has about 150 of them.

The dictionaries of Finder 9.1.1 and Finder 10.0 are similar at first glance, but on closer inspection there are many omissions and new features in Finder 10.0, some reflecting differences in the underlying operating system and others the fruit of an ongoing effort to simplify and rationalize the Finder's dictionary. The difference that has the most serious consequences is the removal of the Computer command from the Finder's dictionary to Standard Additions in Mac OS X, discussed elsewhere in this report.

Other changes are listed here:

The Restart, Shutdown and Sleep commands are missing from the Finder Basics suite, perhaps because this is a multiuser operating system and one of your machine's users shouldn't have that kind of control over the machine.

In the Application class of Finder Basics, the following elements are gone, as are their associated classes: Sharable Container, Sound File, Suitcase, Font Suitcase, Accessory Suitcase, Process, Application Process, Accessory Process, Container Window, Information Window, View Options Window, and Content Space. In some cases, these reflect only the fact that the element has been renamed or moved elsewhere in the dictionary. In others, the omissions reflect omitted or different functionality in the underlying operating system. In still others, I believe they reflect a long-standing desire among the designers of the Finder's dictionary to simplify it by omitting redundant classes without limiting the ability to script the underlying functionality. The Internet Location element is renamed Internet Location File, to match the associated Internet Location File class that was already in the Files and Suitcases (now simply Files) suite. A new Finder Window element is added, which is accessible by numeric index and by ID; you can still rely on the already-existing Window element to access a window by name. Many of these omissions and changes also occur in other classes, such as the Container class, and will not be repeated in this listing.

The following properties are gone from the Application class: Largest Free Block, File Sharing, Sharing Starting Up, About This Computer, and Execution State. I believe some of these will reappear in other places. These new properties are added: Startup Disk, Trash, and Home. Only Home offers new functionality, reflecting the multiuser nature of the operating system.

The Special Folders class is omitted. It had not kept up with advances in the Path To command of the Standard Additions scripting addition, anyway, and had become redundant.

In the Finder Items suite, the Put Away command is omitted because the functionality no longer exists in the Finder. The little-used but very important Update command has acquired a new parameter, Registering Applications, which defaults to true. Somebody needs to explain this one.

The Item class has lost its Id (moved to the Finder Window class), Folder, Selected, Content Space, and Window properties, but it has gained the following new properties: Url, Icon Size, Owner, Group, Owner Privileges, Group Privileges, and Everyones Privileges.

The Sharable Container and Sharing Privileges classes are no longer available in the Containers and Folders suite.

In the Disk class, an important new property is added, Format, which gives you a long list of enumeration constants from which to choose. These include Mac OS Format, Mac OS Extended Format, and UDF Format.

In the Files (formerly Files and Suitcases) class, the Locked property is gone.

The Clipping class has a new Clipping Window property.

The Window class has a new Id property giving the unique id of a window, enabling the new by ID accessor available through the new Finder Window class. The Popup and Pulled Open properties are omitted because popup windows (the tabs along the bottom of the screen) are not available in Finder 10.0, having been replaced by the Dock with its ability to present menus from installed folders.

The Information Window class has been renamed the Inspector Window class. It has not changed, except that the parameters to the Current Panel property are different, reflecting the different way in which the Mac OS X Inspector works.

In the Type Definitions suite, there are new Icon View Options, List View Options and Column classes. These mostly encapsulate already-existing properties, such as the Arrangement property of the Icon View Options class. I am excited about one new property, the Index property of the new Column class, because it is not marked r/o for read-only. This suggests that I may be able to change the order of columns in list view windows via script, which will allow me to move the Version column to second position, next to the Name column, where I want it in all my list windows. But I can't make this work in Finder 10.0.

In sum, there is a lot to learn about scripting the new Finder. The process will be difficult for the time being, because the temptation to blame your failures on system bugs will be unusually hard to resist.

QuickTime Player application
The Standard Suite of QuickTime Player 5.0 has new Data Size and Delete commands. The QuickTime Player Suite is greatly expanded, adding five new classes (Chapter, Display, Frame, Stream, and Text Frame) and nine new commands (Add, Clear, Copy, Cut, Open Image Sequence, Paste, Redo, Trim, and Undo). The Open Location command has a new Position parameter. The Present command has a new Mode property allowing specification of Normal or Slide Show, and a new Display parameter allowing specification of the monitor on which to present a movie. The Application class has three new properties (Clipboard, Ignore Auto Play, and Ignore Auto Present), and the QuickTime Connection Speed property enumerates several new constants. The Display class brings new power to the ability to use AppleScript to understand what monitors are available; for example, on my new PowerBook G4 Titanium, 'dimensions of display 1' returns '{1152,768}'. The Favorite class adds several elements and properties, including the Category of the favorite. The Movie class adds 21 new properties; the Track class, 20 too many to name them all here.

Standard Additions scripting addition

Standard Additions 1.6 in the Mac OS X environment sports a few dictionary changes since Standard Additions 1.5.5. See Testing Whether AppleScript 1.6 is Installed for information about the new System Attribute command. In addition, the Choose Application command's optional Application Label parameter is replaced by With Title. Typing 'application label' will not compile to 'with title'; it won't compile at all. The two parameters serve somewhat different purposes, now that Choose Application does not allow choosing a remote application to link to, but only a local application. Some of the commands now assign plain text as the type of properties that were formerly typed as string.

The Path To command has been enhanced for Mac OS X to deal with multiple domains. There may, for example, be Scripting Additions folders in several individual users' Home folders, and in the main Library folder at the root level of the Mac OS X disk, and in the Library folder in the network domain, in addition to the system-level Scripting Additions folder. To accommodate multiple domains, the Path To command has been given a new From parameter that lets you specify whether to look for the desired special folder in the 'System domain', 'local domain', 'network domain', or 'user domain'. For example, 'path to scripting additions from user domain' returns alias <Mac OS X disk>:Users:<user>:Library:ScriptingAdditions:, where <user> is the user currently logged in, and 'path to scripting additions from local domain' returns alias <Mac OS X disk>:Library:ScriptingAdditions:. The indicated result is returned even if the special folder does not currently exist in the specified domain, and the specified folder is created, as has always been the case but only if the user has privileges to change that domain. The default domain when the From parameter is omitted varies depending on the special folder you designate, based on Apple's sense of which domain is appropriate for that special folder; for example, for scripting additions the default is the System domain, but for preferences it is the user domain. Varying the default domain, instead of having an easy-to-remember fixed default domain for all special folders, was a bold design decision on Apple's part. Some of the defaults may be open to debate. For example, the Scripts Folder and Folder Action Scripts Folder location selectors default to the System domain, but there are no such folders there in the current release of Mac OS X. Since users do not have write access to the System domain, omitting the From parameter for those locations guarantees a run-time error, as described below. Most scripters may find it easiest to use the From parameter in all cases, in order to avoid having to look up the default.

You can get unexpected results if you don't understand just how the Path To command works in Mac OS X. For example, if you run 'path to AppleScript' in Script Editor, it returns an alias to the Script Editor application, but this is only because it is, in effect, interpreting the command to mean 'path to current application'. The same command would return a different result if run from another editor, and it returns the path to itself if run as an applet. Also, if a requested special folder does not exist in the domain in issue, the command will generate an error if the current user lacks write permission for the domain in issue, instead of simply creating the folder as it does in Mac OS 9.1 and earlier. For example, 'path to scripts folder' now returns error number -5000 (known to programmers as afpAccessDenied), because the Path To command defaults to the System domain, which does not contain a Scripts folder and does not let any user create one. The error message is accurate (Folder does not exist, and you don't have access privileges to create it.). In this case, you have to be careful to specify the desired domain; 'path to scripts folder from user domain', for example, works correctly, creating the folder if it does not exist, instead of generating an error. It may also be the case (I haven't tested this) that when the user is logged in as administrator, a script will be able to get the path to a nonexistent special folder from the local domain, while attempting to do so would cause an error if the user is logged in as a normal user without write access to the local domain. The access privileges issue will trip up older scripts that previously worked correctly, in cases where a special folder does not exist in a domain to which the current user lacks write access, and it will undoubtedly trip up new scripts that are not written defensively to test for this issue. Such is the price of progress, for the multiuser capabilities of Mac OS X are a definite advance.

In general, the Mac OS X Standard Additions dictionary retains the classic Mac OS special folder constants for use with the Path To command, but scripts directed at Mac OS X will generate errors if they use constants that are meaningful only in the Classic environment or Mac OS 9.1. This is one of the reasons why you are advised to test your environment before executing script commands that differ as between environments.

Apple's new AppleScript 10.0 Overview gives the following examples of supported Path To locations, some of which must be given as four-character codes in this version of Mac OS X: preferences folder, help folder, desktop pictures folder, At Ease documents folder (At Ease is an anachronism; it refers to the Mac OS X Documents folder), At Ease applications folder (the Mac OS X Applications folder), 'ssnd' (Sounds folder), 'favs (Favorites folder), 'dlib' (Library folder), 'cuser' (the current user's Home folder), temporary items folder, 'usrs' (Users folder), 'root' (the System folder, current user's folder, or Network folder, depending on domain), 'sdat' (Shared documents folder), scripts folder (the folder where Script Runner gets its menu items). In general, for the developers among you, you can use any four-character string that is a FindFolder selector as declared in the Folders.h header file. 9/22/01

The Scriptable Finder

In a sense, the Finder has undergone its most extensive revision since the Macintosh was first released, because it now has to deal with a radically changed infrastructure. Although its dictionary remains very familiar, there are many changes, some of its features are not yet implemented or don't work correctly, and other features may change before too long. Even with the limitations in its current scripting implementation, the Finder remains the enormously powerful tool that it has been since it became scriptable some years ago. For an example of its power, check out the Build web page example script in the Scripts subfolder of the Image Capture folder in the main Library folder.

In considering the many changes to the Finder's dictionary, do not be misled by the fact that the Finder in the Classic environment is still Finder 9.1.1, while the Finder in the Mac OS X environment is Finder 10.0. If you boot into Mac OS 9.1 directly, you will see the familiar Finder 9.1.1 dictionary. But if you boot into Mac OS X and attempt to examine the Finder 9.1.1 dictionary in the Classic environment, you will discover that it has magically transmogrified into the Finder 10.0 dictionary. (You must use the Classic Script Editor to do this, because the Mac OS 9.1 Finder is dimmed and can't be selected if you use the Mac OS X Script Editor's Browse button in an attempt to open its dictionary.) In other words, Finder scripting when booted into Mac OS X uses the same new terminology, no matter which environment your script addresses. When you boot into Mac OS X, you boot into a world where many low-level system hardware and operating system features are controlled by the new Mac OS X kernel, and so the Finder as well as other system-level software must depend upon them in either environment.

I have not exhaustively tested Finder scripting in Mac OS X, but I have found an oddity or two, and many others are already being reported on the mailing lists. For example, the statement 'make new file at desktop with properties {name:Test}' creates a SimpleText file, although SimpleText is not included in the standard Mac OS X installation. When you double-click the resulting file for the first time, SimpleText is launched in the Classic environment. Although this may be appropriate to preserve backward compatibility, I would prefer to see a scriptable RTF Mac OS X application like TextEdit become the new standard for text files. Having to launch the Classic environment to read such a file is a nuisance, and what if the user did not install the Classic environment? (A Carbonized version of SimpleText does appear on the Developer Tools CD, and it runs in the Mac OS X environment; however, it was written as a demonstration of Carbon techniques for developers, not as a standard text editor for Mac OS X. It is not as competent a text editor as TextEdit.) There also appear to be unimplemented or buggy commands in the Finder, still. For example, I can't make the Select command select a specified item, getting error number -10000 if the item exists but the correct error if it does not exist.



Board footer

Powered by FluxBB

[ Generated in 0.071 seconds, 8 queries executed ]

RSS (new topics) RSS (active topics)