AppleScript Release Notes for Mac OS X version 10.5

This release note provides the latest information about AppleScript 2.0, which ships with Mac OS X version 10.5, as well as a list of the more prominent bug fixes. For older release notes, see AppleScript Release Notes (Mac OS X 10.4 and earlier).

AppleScript 2.0 can use scripts developed for any version of AppleScript from 1.1 through 1.10.7, any scripting addition created for AppleScript 1.5 or later for Mac OS X, and any scriptable application for Mac OS 7.1 or later. A script created with AppleScript 2.0 can be used by any version of AppleScript back to version 1.1, provided it does not use features of AppleScript, scripting additions, or scriptable applications that are unavailable in that version.

Contents:

Unicode Support
Application Objects
Scriptable Network Preferences
Scriptability and VoiceOver
Command Line Support
Other Enhancements
Bug Fixes
Developer Notes


Unicode Support

AppleScript is now entirely Unicode-based. Comments and text constants in scripts may contain any Unicode characters, and all text processing is done in Unicode, so all characters are preserved correctly regardless of the user’s language preferences. For example, this script works correctly in AppleScript 2.0, where it would not have in previous versions:

set jp to "日本語"
set ru to "Русский"
jp & " and " & ru -- returns "日本語 and Русский"

There is no longer a distinction between Unicode and non-Unicode text. There is exactly one text class, named “text”: that is, class of "foo" returns text. It is functionally equivalent to the former Unicode text class, so it may contain any Unicode character, and has two new features besides:

Matching of text item delimiters now respects considering and ignoring attributes, where previous versions ignored them. The expansion attribute is no longer supported.

The change to all-Unicode necessitated a change in the read and write commands and how they deal with text encodings. Formerly, they would write string objects using the primary encoding and Unicode text objects as UTF-16, unless instructed otherwise using an as parameter. Now that there is only one text class, the read and write commands rely solely on the as parameter to determine the encoding: with no as parameter, as text, or as string, they use the primary encoding; with as Unicode text, they use UTF-16. For the most reliable results when creating scripts that will run on both 2.0 and pre-2.0, always specify the encoding explicitly using as text or as Unicode text, as appropriate. [4421553]

Compatibility

For compatibility with pre-2.0 AppleScript, string and Unicode text are still defined, but are considered synonyms for text. For example, all three of these statements have the same effect:

someObject as text
someObject as string
someObject as Unicode text

In addition, text, string, and Unicode text will all compare as equal. For example, class of "foo" is string is true, even though class of "foo" returns text. It is still possible for applications to distinguish between the three different types, even though AppleScript itself does not.

Now that AppleScript preserves all characters correctly worldwide, it is also stricter about the text used in scripts. AppleScript syntax uses several non-ASCII characters, such as “≠” and “¬”. These characters must be typed exactly as the AppleScript Language Guide describes. For compatibility with Asian national encodings, “《” and “》” are allowed as synonyms for “«” and “»”, since the latter do not exist in some Asian encodings.

Because all text is Unicode text, scripts now always get the Unicode text behavior. This may be different from the former string behavior for some locale-dependent operations, in particular word elements. To get the same behavior with 2.0 and pre-2.0, add an explicit as Unicode text coercion, for example, words of (someText as Unicode text).

Because text item delimiters now respect considering and ignoring attributes, they now are case-insensitive by default. Formerly, they were always case-sensitive. To get the same behavior with 2.0 and pre-2.0, add an explicit considering case statement.

Because AppleScript 2.0 scripts store all text as Unicode, any text constants count as a use of the former Unicode text class, which will work with any version of AppleScript back to version 1.3. A script that contains Unicode-only characters such as Arabic or Thai will run, but will not be correctly editable using pre-2.0 AppleScript: the Unicode-only characters will be lost.

Use of the new id property requires AppleScript 2.0.

Application Objects

application objects in AppleScript have some new features designed to reduce the need for awkward or obscure workarounds. In other words, the capabilities are not new, but they are now directly supported and easier to use.

In addition, there are several changes to application behavior to make them easier to deal with:

Compatibility

Uses of the built-in application properties will fall back to sending an event to the application in older versions of AppleScript, but the application may not handle them the same, or handle them at all. (Most applications will handle name, version, and frontmost; id and running are uncommon.) The other new features above require AppleScript 2.0.

Scriptable Network Preferences

Networking preferences are now accessible via scripting using a new suite in System Events, where they were previously only scriptable via accessibility. A script can inspect various networking settings, and can tell a service to connect or disconnect. For example, the following script locates a PPPoE service in the current location and tells it to connect if it exists.

tell application "System Events"
    tell network preferences
        tell current location
            set aPPPoEService to a reference to (first service whose kind is 10)
            if exists aPPPoEService then
                connect aPPPoEService
            end if
        end tell
    end tell
end tell

Scriptability and VoiceOver

AppleScript Utility and Folder Actions Setup are now scriptable, and Script Editor’s scriptability has been enhanced thanks to improvements in Cocoa Scripting. All three applications are now VoiceOver-aware.

Command Line Support

AppleScript now allows # as a comment-to-end-of-line token, in addition to --. This means that you can make a plain text AppleScript script into a Unix executable by beginning it with the line #!/usr/bin/osascript and giving it execute permission. For details of osascript usage, including how to access command line arguments from the script, see the osascript(1) man page. [2468788]

There is a command-line tool to display compiled scripts as text, /usr/bin/osadecompile. [4501123]

osascript(1) and osacompile(1) now correctly handle text scripts encoded as UTF-8, in addition to UTF-16 and the primary encoding. If a script is neither UTF-8 nor UTF-16, it is presumed to be encoded using the primary encoding.

Compatibility

Compiled scripts that use # will run normally on pre-2.0 systems, and if edited will display using --. Executable text scripts using #!/usr/bin/osascript as above will not run on pre-2.0 systems, since the # will be considered a syntax error.

Other Enhancements

Script Editor

System Events

Image Events

Bug Fixes

AppleScript

Standard Additions

Script Editor

System Events

Others

Developer Notes

Scripting Definitions (sdefs)

AppleScript can now read an application’s sdef directly. This means that an application with only an sdef no longer needs to be launched to get its scripting terminology. [4569425]

There are a few changes to the sdef format itself; see the sdef(5) man page for details. In particular, sdefs now support the use of XInclude. Applications that process sdefs should be prepared to handle them. The 10.4 sdef format is still supported, but you should migrate when you have the opportunity.

API changes

Several Open Scripting Architecture (OSA) APIs have new replacements, mostly intended for improved handling of Unicode script content. Except as noted, the new APIs are available in Mac OS X version 10.5 and later, and the old APIs are still available and supported, though they do not support the new functionality. For additional details, see the Open Scripting Architecture Reference.

old

new

OSAGetSource, OSADisplay

OSACopySourceString, OSACopyDisplayString

These return their output as a CFAttributedStringRef, which means they can handle styled Unicode text, where the older two cannot. If a language component does not support OSACopySourceString or OSACopyDisplayString directly, calls to them will be passed through to OSAGetSource and OSADisplay, respectively.

ASGetSourceStyles, ASSetSourceStyles

ASCopySourceAttributes, ASSetSourceAttributes

These use a CFArray of CFDictionaries of attributes to apply to the CFAttributedStringRef returned by OSACopySourceString and OSACopyDisplayString.

OSAGetAppTerminology

OSACopyScriptingDefinition

OSACopyScriptingDefinition is available in Mac OS X 10.4 and later; OSAGetAppTerminology is not available in 64-bit.

OSALoadFile and OSADoScriptFile now correctly handle text scripts encoded as UTF-8. [4490939]

The various OSADebugger APIs, which have been marked as “not implemented” for some time, have been completely removed. [3918369]

Scripting Additions

Scripting additions may be written using a new architecture which is both easier to write and improves performance. See Scripting Additions for Mac OS X for details. [4236732]

The scripting addition loader will search the directory specified by the environment variable DYLD_FRAMEWORK_PATH. Xcode sets this variable to the build product directory when you run your executable, which means you can run and debug a scripting addition project directly from Xcode without first installing the scripting addition. [5027805]





© 2007 Apple Inc. All Rights Reserved. (Last updated: 2007-12-11)


Did this document help you?
Yes: Tell us what works for you.
It’s good, but: Report typos, inaccuracies, and so forth.
It wasn’t helpful: Tell us what would have helped.