AppleScript_ The Definitive Guide - Matt Neuburg [43]
I'll talk about how you specify a target application in your script, and how to do so in such a way that AppleScript stands the best chance of just compiling the script without asking for human assistance, in "Tell" and "Using Terms From" in Chapter 19, and in "Application" in Chapter 13.
Application Missing at Decompile Time
Decompilation takes place when you open a compiled script file for editing; the bytecode of the compiled script file is illegible, so it must be decompiled in order to be displayed (and pretty-printed). When a compiled script file is decompiled, AppleScript needs each application targeted by that script, but for the opposite of the reason why this happens at compile time. When a script is compiled, AppleScript needs a dictionary so that it can translate the English-like AppleScript code into Apple events in the bytecode. When a script is decompiled, AppleScript needs a dictionary so that it can translate the Apple events of the bytecode into English-like AppleScript code.
Once again, AppleScript starts by trying to find the application on its own. And again, I do not know the exact steps involved here, but experimentation shows that if the application is actually running at decompile time or is present on disk and its name has not changed, AppleScript usually finds it easily. The compiled script also contains an alias to the application, which means that even if you change the application's name, or move it to a different folder on the same volume, the compiled script should continue to keep track of it.
Nevertheless, there can be circumstances under which AppleScript cannot find the application on its own—perhaps you moved the application to a different volume, or the script is being opened on a different machine where the application is missing or has another name—so when you try to open the script in your script editor application, you'll get the dialog asking you to locate it. At this point, one of three things can happen:
You cancel out of the dialog.
The script editor application fails to open the compiled script file.
You locate the correct application.
The compiled script opens; the script is modified so that the reference to the application points at it in its current location.
You locate some other application.
The compiled script opens; the script is modified so that the reference points to the application you located, and any terms not resolved by the nominated application's dictionary are shown in raw form.
Warning
In the second and third cases, even though the script is modified, this does not "dirty" the script file itself. So you can then close the script window, and the script editor application will not ask whether you want to save; therefore the knowledge of the application's new location won't be written into the compiled script file, and you'll have to go through the whole rigmarole again the next time you open the file. I regard this as the fault of AppleScript, which apparently has no way to alert the script editor application that the compiled script has changed. The workaround is to modify the script manually—just insert a space somewhere—and compile and save it.
The third possibility is surprising. Recall that when you try to compile a script, if AppleScript asks you to locate an application and you locate some other application, one that doesn't resolve the terms used, AppleScript knows you're lying, and compilation fails. But when you decompile a script, if AppleScript asks you to locate an application and you locate some other application, decompilation succeeds. This can be quite useful, because it means you can open a script for editing, and even read most of it, even if you're missing one of the applications needed to run it.
For example, consider this script targeting Eudora: