• Choose a category
• All
• Classic-Fiction

At any given point in a script, up to four sets of vocabulary are in force: the target application's dictionary, the dictionaries of all loaded scripting additions, AppleScript's own dictionary, and any other terms created and used by the programmer in the course of the script. These namespaces are not readily distinguished, and collide in confusing and frustrating ways.

For a vivid demonstration of how an AppleScript programmer's time is spent wrestling with the target application's dictionary, please pause and read Appendix A. Dictionaries and the problems associated with them are studied in depth in Chapter 20. Some alternative tools for displaying the contents of an 'aete' resource are listed in Appendix C.

Missing External Referents

AppleScript is a little language, leaving it up to externals such as scriptable applications and scripting additions to extend the vocabulary of the language as needed. A consequence of this architecture is that at various crucial moments during the life of a script, such as when it is compiled, decompiled, or executed, AppleScript will look for externals, and may complain if it can't find them. This section talks what happens on these occasions.

Application Missing at Compile Time

When a script is compiled, AppleScript needs each application targeted by that script, so that it can obtain its dictionary to verify the legality of the terms the script is using and to translate those terms into Apple events in bytecode. If it can't find a targeted application, it will present a dialog asking you, the human user, to locate it. At this point, one of three things can happen:

You cancel out of the dialog.

The script won't compile.

You locate the correct application.

The script compiles, and is modified to point to the application you nominated.

You locate some other application.

The script won't compile.

What consitutes "the correct application" is any application whose dictionary defines the terminology AppleScript is trying to verify. To see what I mean, let's start with code like this:

get disk 1

If that's all your script says, it won't compile at all, because the term disk isn't part of the AppleScript language. You can use it this way only while targeting a scriptable application that extends the AppleScript language to include a class called disk. Now, suppose we pretend there is such an application, making up a name for this application when in fact we have no application by that name. Let's call it NoSuchApp.

tell application "NoSuchApp" to get disk 1

When you try to compile this, you're presented with a dialog listing every application, and posing the question: "Where is NoSuchApp?" AppleScript has realized that although the term disk is meaningless in the AppleScript language proper, it might be meaningful in the context of the application NoSuchApp. AppleScript therefore attempts to find the application. (I do not know the exact steps used in the search.) But NoSuchApp can't be found , because there's no such app. So AppleScript turns to you for help. If you cannot at this moment locate NoSuchApp—if, for example, you cancel out of the dialog—the script will simply not compile.

Instead of cancelling, you can nominate an application as NoSuchApp—any application, even if it isn't called NoSuchApp. This makes sense because the problem might merely be that the name has changed or you've typed it wrong. For example, you could claim that NoSuchApp is Address Book (just select Address Book in the dialog, and click Choose). However, this does not fool AppleScript for long, because it immediately turns to Address Book's dictionary and investigates its vocabulary. AppleScript quickly concludes you were lying, because Address Book doesn't know what a disk is after all—and the script still won't compile.

Now suppose we try again to compile, and this time, when AppleScript asks us about NoSuchApp, we tell it that NoSuchApp is the Finder.