Enhanced Application Object Model
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.
Is an application running?
While the scripting support in the System Events application is capable of determining whether or not an application is running, doing so is an involved process of getting the application indentifers of the currently running processes, and then scanning that list for specific applications. In Mac OS&nbps; Leopard Application Objects now have a running property that can give you the answer directly, without invoking System Events. For example, the following script pauses iTunes, but will not launch iTunes if it is not already running:
Using the running application property to determine if an application is active:
tell application "iTunes"
if it is running then
pause
end if
end tell
The running property does not need to appear inside a tell block; the above script could also be written like this:
The running application property can be used to limit the execution of scripts to run only when applications are open or only when application are not open:
if application "iTunes" is running then
tell application "iTunes" to pause
end if
Get an application’s version
Most applications have a version property of their own, but using it requires that the application be running, and sometimes you specifically want to avoid that. The new built-in version property will return the application version as text without launching the application or sending it an event. There is also a corresponding built-in name property; the value is usable as the name of an application to tell.
Target applications by signature or bundle identifier
Sometimes you may want to target an application with a script but you’re not sure how the application is named. In Leopard, it is now possible to simply address an application object by id, where the id is either the four-character signature code or the bundle identifier. For example, application "Mail", application id "emal", and application id "com.apple.Mail" all refer to Mail.app, and will all work as the target of a tell block.
If you’re not sure of what an application’s bundle indentifier is, you can use the id property to get it:
A script demonstrating how to get the value of the id property of an application, and how to use an application's id to address the application:
get id of application "TextEdit"
--> "com.apple.TextEdit"
tell application id "com.apple.TextEdit"
make new document
end tell
Note that getting the value of the id property does not require that the application be running. Locating applications by id is superior to locating them by name, since users can change the application name. However, this is usually only an issue for scripts distributed to others.
Changes in Application and Script Behavior
There are two changes to application behavior to make them easier to deal with:
- Applications launch hidden
AppleScript has always launched applications if it is necessary to send them a command. However, by default they would launch in front, possibly obscuring whatever the script was attempting to show. AppleScript now launches applications hidden by default. They will not be visible unless the script explicitly says otherwise using launch, activate, or set frontmost to true.
- Applications are located and re-located dynamically
Application object specifiers, including those in tell blocks, are evaluated every time the script runs. This alleviates problems with scripts getting “stuck” to a particular copy of an application.
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.