AppleScript_ The Definitive Guide - Matt Neuburg [45]
If an applet, as it launches, asks you to locate a missing application and you do locate it, the applet may proceed to run correctly. But knowledge of the missing applications location is not written into the applet, so the same thing will happen next time the applet is launched. The only solution is to open the applet for editing (if it hasn't been saved as run-only) and fix it in a script editor application.
A puzzle therefore arises of how to permit an applet, if it contains code that might never be executed and that targets an application that might be missing, to run at all—in other words, how to make an applet behave like a compiled script file in this regard, postponing the question of where an application is until the script runs and code referring to that application is actually encountered. This puzzle used to be rather difficult to solve, but with the invention of the terms block (one of the few major linguistic changes in the history of AppleScript), there is in fact a rather slick workaround. I'll explain what it is in "Using Terms From" in Chapter 19.
Scripting Addition Missing
Up to now we've been talking just about missing applications. But what if what's missing is a scripting addition? AppleScript can't present any kind of dialog pointing out that such-and-such a scripting addition is missing, because it has no idea where the troublesome terminology was supposed to come from. This is because you don't target a scripting addition; you just use its terminology directly as if it were part of the language. So if the scripting addition isn't there, then this terminology isn't part of the language, and that's all AppleScript knows about what the problem is. You're talking illegally, but AppleScript doesn't know why. So what happens? It depends on what you're trying to do:
You're trying to compile the script.
The script simply won't compile. In the absence of the scripting addition that defines a certain term, that term is illegal, and a script that uses illegal terminology can't be compiled.
You're trying to decompile the script.
All other things being equal, you'll succeed. The terminology from the missing scripting addition is shown in raw four-letter form; AppleScript can't find the scripting addition's dictionary to resolve it back into English-like AppleScript code, so it just shows you the Apple event that's stored in the compiled script's bytecode. This makes sense, because if AppleScript refused to decompile the script merely because it contains an unknown Apple event, you'd probably never be able to read the script again, since AppleScript has no way of knowing or informing you of what the problem is—namely, that a certain scripting addition is missing. Of course, now that you've seen the raw four-letter code of the Apple event, you probably have no way of knowing what the problem is either. Even if you can guess that a scripting addition is missing, how can you know what scripting addition it is, unless you've got a list of all the raw four-letter codes of all possible scripting additions? (This is just one of many ways in which scripting additions are troublesome.)
You're trying to execute the script.
The script will run until it comes to the offending Apple event, and then things will probably choke. That's because this Apple event is going to be sent either to some target application or to AppleScript itself, and either way it isn't going to be defined in the repertory, so an error message will come back. Unless the script handles this error, execution will come to a stop and the error message will be displayed; it may well include the four-letter code of the Apple event (for all the good that's going to do you).
Modes of Scriptability
An application is scriptable if it defines a repertory of Apple events to which it is