AppleScript 1.7 for Mac OS 9 and Classic is the version of AppleScript that is installed by Software Update 9.2.2 on Mac OS 9 systems. It is primarily intended for use in the Classic environment of Mac OS X, and for scripters who are expecting to migrate their scripts and applications to Mac OS X.
The main features of this release provide script interchangeability with AppleScript 1.7 on Mac OS X.
This release also fixes 29 problems in AppleScript that are present in AppleScript 1.6 on Mac OS 9.
AppleScript 1.7 can use scripts developed for any version of AppleScript from 1.1 through 1.6 on Mac OS 9 (and 1.5 through 1.8.1 on Mac OS X), any scripting addition created for AppleScript 1.1 or later (except scripting additions created exclusively for Mac OS X), and any scriptable application for Mac OS 7.1 or later.
A script created with AppleScript 1.7 can be used by any version of AppleScript from 1.1 through 1.8.1, provided it does not use features of AppleScript, scripting additions, or scriptable applications that are unavailable in that version.
| FEATURES: |
Standard Additions
In AppleScript 1.7 and later, AppleScript will load Standard Additions that are configured as "bundles" or "packages."
AppleScript Language
All Mac OS Extended ("HFS Plus") format disks can store files with file names in Unicode text and longer than 32 characters. When older software accesses such files, those names are represented in an encoded form (with something like "#28AF" in the name). With AppleScript 1.6 and earlier, the results of many Standard Additions commands (like path to, info for, and list folder), as well as creation and display of alias and file objects, required and returned encoded names. In AppleScript 1.7, all file names are represented as Unicode text. Encoded file names are no longer supported. Note that the Finder in Mac OS 9 only supports encoded names, but the Finder in Mac OS X and Classic only supports long names.
In most cases this change will be transparent, but some applications or scripting additions may not be able to understand the new data format. For such applications, use as alias when sending a file object to an application or scripting addition. You may also notice that file and alias pathnames are now displayed in the default application font instead of the "Values" style defined in AppleScript Formatting.
Because many Mac OS X files use UNIX-style line endings (using the linefeed character, or ASCII character 10), AppleScript versions 1.7 and later explicitly support embedding the linefeed character in strings by using the sequence "\\n". Scripts that use this feature can be run on older versions of AppleScript, but if decompiled, the linefeed character will not be visible in the decompiled output (but will recompile correctly).
Script Applications ("applets")
Prior to AppleScript 1.4.3, script applications ("applets") were stored in a "universal" format that worked on both 680x0-based and Power PC-based Macintosh models. Because that format was 680x0-based, it would not work on Mac OS X, so a "Mac OS X applet" format was introduced in AppleScript 1.4.3. With improvements in Mac OS X since that time, it is now possible to produce a script application that works on 680x0-based, Power PC-based Mac OS 9, and Mac OS X configurations. Script Editor 1.7 again offers only one choice for saving script applications. Older formats continue to work on the configurations they were saved for. Note that a "universal" applet will run native in Mac OS X when double-clicked in the Mac OS X Finder. If you would like it to be executed in the Classic environment (to take advantage of older Standard Additions, for example), set the "Open in the Classic environment" check box in its Finder Get Info panel.
| BUG FIXES: |
AppleScript Language
Certain operations in third-party script editors and debuggers are unstable with AppleScript 1.6 and earlier. AppleScript 1.7 for Mac OS 9 and Classic makes those debuggers more stable.
AppleScript 1.5.5 and 1.6 would fail when attempting to convert a file path string to a file specification, either by explicit coercion ("Macintosh HD:" as file specification) or as an object reference (file specification "Macintosh HD:"). This is fixed in AppleScript 1.7 and returns the generic file form (file "Macintosh HD:").
In AppleScript 1.6, conversions from Unicode text to plain text worked in AppleScript itself, but would not work if invoked by applications. This caused problems when sending Unicode text to applications that expected plain text. This has been fixed in AppleScript 1.7.
In AppleScript 1.6, Unicode text values stored in script properties of a saved script could not be reloaded reliably. This has been fixed in AppleScript 1.7.
In AppleScript 1.6, Unicode text received from certain applications that included a Unicode byte-order mark would behave incorrectly; the text would appear to begin with the Euro symbol, and some operations would fail. AppleScript 1.7 handles Unicode text with byte-order marks correctly.
AppleScript 1.6 on Mac OS 9 and Classic cannot get any information about process objects of the Finder on a Mac OS X machine. AppleScript 1.7 on Mac OS 9 and Classic can do this.
Accessing paragraphs of AppleScript strings did not work correctly in AppleScript 1.5 through 1.6 if the line endings were Windows-style (CRLF). The result would be only the first half of the text paragraphs, interspersed with an equal number of blank strings. This has been fixed in AppleScript 1.7 and later.
AppleScript 1.5 through 1.6 on Mac OS X often launched applications unnecessarily in order to get their terminology, and often used the terminology of the script editing application (such as Script Debugger) instead of application terminology. This has been fixed in AppleScript 1.7.
In AppleScript 1.5 through 1.6, a script's global variables could be lost under certain rare circumstances. If a script contains a tell block that targets a variable, and that variable specifies an application that does not exist, the "Where is application <name>?" dialog would be presented when the script is executed. After that point, further references to global variables in the handler that included the tell block would fail. This has been fixed in AppleScript 1.7.
In somewhat rare circumstances, comparing two references to the same file for equality can fail even if both references refer to the same file. This is true in AppleScript 1.0 through 1.6 and has been fixed in AppleScript 1.7.
AppleScript 1.6 for Mac OS 9 and AppleScript 1.7 for Mac OS X have different ways of storing the address of a remote machine using the "eppc://" URL type. A script that targets a remote application that was created on Mac OS X cannot be used by AppleScript 1.6 on Mac OS 9 or Classic, but can be used by AppleScript 1.7 for Mac OS 9 or Classic. Note that scripts created by AppleScript 1.1 through 1.7 on Mac OS 9 or Classic that target remote applications cannot be read by AppleScript 1.7 on Mac OS X at all, but can be read by AppleScript 1.8 on Mac OS X.
Due to a problem in AppleScript's script parser, the language formations isn't, doesn't, and possessives ending with "'s" would all accept a vertical bar or a double-quote character in place of the s or t following the apostrophe. In AppleScript 1.7 and later, these constructions (for example, "doesn'|" or "AppleScript'" version") are correctly noted as syntax errors.
Script Editor
Script Editor 1.4.3 through 1.6 displayed an unhelpful error message if you attempted to print a script without first selecting a printer in the Chooser. Script Editor 1.7 displays a more descriptive message.
With Script Editor 1.4.3 through 1.6, using the "Paste Reference" menu item would not work properly if the Clipboard contained more than one selected Finder file. This has been fixed in Script Editor 1.7.
Script Editor 1.6, when trying to save a script that could not be compiled, would display an error message that read, "The %1$@ "%2$2" wouldn't compile; you won't be able to save it in compiled form, only as text." This has been fixed in Script Editor 1.7 to display the correct script name.
AppleScript Applications: Applets
In AppleScript 1.4.3 through 1.6, a running AppleScript applet would become non-responsive to any events (except command-period) after processing some incoming events. This has been fixed in AppleScript 1.7.
In AppleScript 1.6, under certain circumstances, calling a handler in an applet that has not been launched could cause a "Can't continue" error. This has been fixed in AppleScript 1.7 and later.
Standard Additions
In Standard Additions 1.6 and earlier, the info for scripting addition would fail if any piece of information in the requested file or directory was unavailable. On UFS disks (DVD-ROMs and certain Mac OS X disks) and mounted NFS volumes, the file creation date is unavailable, and accessing it causes a -8850 error (in trying to convert it to Universal Time). Starting with Standard Additions 1.7, any missing piece of information in the info for result is provided as the value missing value without failure. In AppleScript 1.6 and earlier, magnitude comparisons (<, =<, >, >=) against the missing value would signal a coercion error for most types; in 1.7 and later, these comparisons always return false without error. These two changes ensure that scripts that use info for against UFS and NFS volumes do not fail, though they may not get correct results because any comparison to the creation date is always false.
In Standard Additions 1.6 on both Mac OS 9 and Mac OS X, the info for scripting addition would return an error -1401 for a nonexistent file, rather than the normal -35 returned in previous versions. In Standard Additions 1.7 trying to get the info for a nonexistent file (or a file in a nonexistent directory or inaccessible disk) will return the customary -35 error.
Mac OS 9.1 introduced the concept of a "package" application, that is, an application composed of a folder of several files and folders, which is treated as an integral application by the Finder and other files. The info for scripting addition in AppleScript 1.6 and earlier treated such packaged applications as folders, not files, and would not return application-related information about them. In Standard Additions 1.7 and later, getting the information for any directory (including package folders) returns an additional record item package folder; if this Boolean value is true, then the directory is a package, and the application's type and creator are provided in the record. Note that info for in Mac OS 9 cannot return the name extension and displayed name record items provided in Mac OS X.
In Standard Additions 1.6, canceling the dialog box presented by the choose application command does not return error -128, as it does in most other scripting additions. This has been fixed in Standard Additions 1.7.
The choose from list command in Standard Additions 1.4 through 1.6 allowed the scripter to create a situation where it would return an empty selection even if the scripter specifically disallowed that case. (This can be done by providing a default item that does not appear in the list). In Standard Additions 1.7 and later, the "OK" button will not be enabled in such cases.
In versions of Standard Additions prior to 1.7, the choose URL command's using editable URL parameter was present in the Standard Additions dictionary but was nonfunctional (URLs were always editable regardless of the setting of the parameter). It behaves correctly in Standard Additions 1.7 and later: if set to false, the user can choose a URL only by browsing, not by editing the URL in the text box.
From AppleScript 1.1, the offset of scripting addition command has not worked correctly when the direct parameter is styled text. It also has not worked correctly with the newly-introduced Unicode text type. In Standard Additions 1.7 and later it produces correct results with both styled and Unicode text. Note, however, that this introduced a problem in which offset of will not work correctly with styled text from some sources (notably the the clipboard command).
The read command in Standard Additions 1.6 had specific problems with the using delimiters parameter: in previous versions, read f as list using delimiters {tab} would return a list, but in AppleScript 1.6, it returned a list of one-item lists. In AppleScript 1.7 and later it behaves as it did prior to version 1.6.
The read command in Standard Additions 1.6 had specific problems with the before and until parameters if used in conjunction with the as parameter. Instead of returning a value of a given type, it would return random data or an error. This has been fixed in Standard Additions 1.7 and later.
Standard Additions 1.5 through 1.6 changed the way that the random number seed worked in the random number scripting addition. Older versions used the system clock as the seed value if no seed value (or a seed value of 0) was provided; Standard Additions 1.5 and 1.6 always use a seed value of 0 in these cases. In Standard Additions 1.7 the older behavior has been restored. In addition, the seed value is now taken from the 60Hz "ticks" counter rather than the system clock, because the increased speed of new machines makes it more likely that two consecutive random number calls may receive the same system clock time as their seed value.
In Standard Additions 1.5 and 1.6, the random number command generated numbers that were not evenly distributed across the range: the first and last values in the random number range would occur far less frequently than other numbers in the range. This has been fixed in Standard Additions 1.7.
In Standard Additions 1.6, the store script command would crash if no in parameter was supplied. This has been fixed in Standard Additions 1.7: if the in parameter is omitted, a Navigation dialog is presented and the file is saved in the file the user specifies.
Previous versions of Standard Additions improperly list the parameters for the store script command. Both the direct parameter (the script) and the in parameter (the file) are optional. If the script is omitted, an empty script is stored in the file; if the in parameter is omitted, the user is prompted for a file name.
| DEVELOPER RELEASE NOTES: |
Historically, when an application is sent an event that contains a whose clause, AppleScript includes a 'cons' attribute (enumConsiderations) that contains a list of AppleScript consideration enumerators that are currently ignored (such as case, application responses, etc.) This is incomplete, awkward to traverse, and not useful to events that don1t include Whose clauses. As of AppleScript 1.7, every event sent by AppleScript to an application or scripting addition includes a 'csig' (enumConsidsAndIgnores) attribute whose value is a typeUInt32 bit field with bits set for every consideration or ignore currently in effect.
To support a wider variety of sources of script text, the compiler in AppleScript 1.7 and later now accepts all three prevalent styles of line endings: Macintosh style (carriage return, ASCII 13), UNIX style (linefeed, ASCII 10) and Windows style (CRLF, ASCII 13-ASCII 10). Decompiled source will continue to be Macintosh-style.
As of AppleScript 1.7, the keyAEKeyData field of object specifiers with keyAEDesiredClass of cFile or typeAlias is now typeUnicodeText, rather than typeChar. This allows us to store long Unicode names in object specifiers. All appropriate system coercion handlers have been changed to accommodate this, so coercing an object specifier to typeAlias, typeFSRef, typeFileSpecification, or typeFileURL will work correctly. If your code specifically unpacks an object specifier, and tries to get the keyAEKeyData as typeChar, automatic coercions will operate, but they may only produce characters in the current system script. For Mac OS 9.2.2 and later, you should update your applications or scripting additions to use the Unicode pathname APIs to the file system, and use the long Unicode path names provided in these object specifiers.
Bug Fixes (Developer)
The AppleScript component would be left in an indeterminate state after a call to OSASetProperty, and would often fail or crash on a subsequent operation. This has been fixed in AppleScript 1.7 for Mac OS 9 and Classic.
The return value from the OSAScriptError function historically returned an error range that was a record of two short integers. This was inaccurate for script text that was greater than 32K in length. AppleScript 1.7 and greater returns a record of two typeLongInteger values. Existing code that gets these values as typeLongInteger would have coerced too-small results and will now work correctly; older applications that expected short integers and only allocated sufficient space for them will continue to get erroneous results on long scripts, and should be revised to accommodate the new return value.
| KNOWN BUGS IN APPLESCRIPT 1.7 FOR MAC OS 9 AND CLASSIC |
AppleScript
If the clipboard contains text that is not styled, the the clipboard scripting addition command will return a styled text value that is malformed and causes the offset of command to crash. Convert the clipboard value to Unicode text before using the offset of command.
Certain AppleScript development environments can create scripts whose parent property is an application object, rather than a top-level script. Attempting to get any parent properties of such objects will cause AppleScript to crash.
There are some reports of serious performance degradation with some scripts and some applications in AppleScript 1.7 on Mac OS 9.2.2. Running the script in the Script Editor or a third-party editor, rather than in a script application or an application's own Script menu, often seems to restore expected performance.
Attempting to execute a script in Claris Emailer when running in the Classic environment will cause Claris Emailer to crash.
Operations on file and alias objects may fail if the name of any folder containing the designated file contains a non-English character (for example, Japanese text, accented characters, or certain symbols). Note also that for forward compatibility with Mac OS X, volume names are now case-sensitive in AppleScript. This is true in Mac OS X and is enforced in Mac OS 9 to maintain compatibility.
The Finder in Mac OS 9 returns values for special folders
(desktop, system folder, etc.) that are incompatible with many commands
in Standard Additions 1.7. To avoid this problem, either use the
path to command to get references to these
special folders, or coerce the Finder's references to aliases before
using them with Standard Additions commands (or third-party scripting additions). For example:
tell application "Finder"
info for desktop
end tell
should be changed to either:
info for (path to desktop folder)
or changed to:
tell application "Finder"
info for alias desktop
end tell
AppleScript 1.7 will fail on its first attempt to access a process object of the Finder running on a remote Mac OS X machine. (It will succeed on remote Mac OS 9 machines, on local Mac OS X machines [e.g. from Classic to X], on any other property or element of the Finder other than process, and on any process object after the first attempt).
In AppleScript 1.6 and earlier, the alias and file classes previously used Macintosh File System functionality to interpret pathnames. As a side effect, expressions like alias ":" and file (myPath & "::") would do interesting things, like return an alias to the directory containing the current application, or navigate up a file hierarchy. In AppleScript 1.7 and later, alias and file support long and Unicode file and path names, using Core Foundation functionality to interpret pathnames, with different side effects. On Mac OS X, alias ":" specifies the root directory, and on both Mac OS 9 and X, sequences of multiple colons are ignored. To get the path to the current application, use path to me; to navigate up a folder hierarchy, use the Finder's container property.
A Macintosh with Mac OS X installed that is booted into Mac OS 9 cannot run Mac OS X applications. If you try to open a script that targets a Mac OS X application in a tell block, it will display the "Where is application (name)?" dialog; if you select a Mac OS X application, AppleScript will fail with the error "File (name) not found." This error message is somewhat misleading; the actual error is that you selected a Mac OS X application that cannot be used on Mac OS 9.
Script Editor
The "Open Dictionary" menu command in Script Editor 1.7 will not display the iTunes 2 application. If you want to view the iTunes 2 dictionary, drag iTunes 2 (or an alias to it) and drop it on the Script Editor application icon.
Scripting Additions
In Standard Additions 1.7, if the path to command is requested to return the path of a folder that does not exist, it will fail. In previous versions it would create the folder and return the path to the created folder.
The dictionary entry for the choose application command erroneously lists a multiple selections allowed optional parameter. This parameter is available in Mac OS X only and is ignored in Mac OS 9.
The open for access command in
Standard Additions 1.7 does not set the type and creator of
newly-created files to type 'TEXT', creator 'ttxt',
so the files cannot be read by most other applications or double-clicked in the Finder.
In the following example, after creating file this_file, perform the following steps:
tell application "Finder"
set file type of file this_file to "TEXT"
set creator type of file this_file to "ttxt"
end tell