AppleScript_ The Definitive Guide - Matt Neuburg [44]
tell application "Eudora"
get subject of message 1 of mailbox "Trash"
end tell
Let's say we compile this script and send it to a friend who doesn't have Eudora. Our friend tries to open the script in a script editor application. AppleScript can't find Eudora, so it asks our friend where it is. At this point, let's say our friend nominates another application—let's say it's the Finder. The script opens, but the terms subject, message, and mailbox aren't defined in the Finder's dictionary, so some raw four-letter Apple event codes are displayed (and the Finder is substituted for Eudora as the targeted application):
tell application "Finder"
get «class euSu» of «class euMS» 1 of «class euMB» "Trash"
end tell
Our friend can now read and edit the script. Those things in funny double angle-brackets are actually raw four-letter codes from the Apple event stored in the bytecode. (See "What an Apple Event Looks Like," earlier in this chapter; raw four-letter codes are further discussed in Chapter 20.) The script is already compiled, so now it is possible to run it—though it probably won't run properly, because the Finder will complain when it is sent an Apple event it doesn't understand.
Warning
Once in a while, AppleScript will misidentify a target application when a compiled script file is moved to a different machine. I don't know the exact causes, but I've seen it happen, and when it does, it's very bad, because not only does the script not work properly, but also, when you open the script to investigate, AppleScript has changed the name of the target application during decompilation—so you have no way to learn what the correct target application is.
Application Missing When a Compiled Script Runs
When a compiled script file is executed directly without opening it for editing—as, for instance, in a script runner—it is not decompiled, and so it does not face quite the same issues as it does during decompilation. AppleScript in this case doesn't look for an application until the script is already running and it encounters code referring to that application. Thus, a targeted application may be missing, but if the code referring to it is never actually executed, there is no problem.
So, for example, this compiled script file runs perfectly well in a script runner on a machine without Eudora:
if 1 = 2 then
tell application "Eudora"
get subject of message 1 of mailbox "Trash"
end tell
else
display dialog "No problem!"
end if
The reason is that because of the branching code (and because 1 is not 2) the material about Eudora is never encountered, so the issue of where Eudora is and what all those terms mean never even arises.
If, on the other hand, such material is encountered, and the AppleScript scripting component can't find the target application on its own, what happens depends upon the context. Sometimes the dialog appears asking you to locate the application (as, for example, in BBEdit); but sometimes it doesn't (under Apple's Script Menu, for example, the script will simply fail silently). Furthermore, having helped the AppleScript scripting component find the application, you'd like that information to be saved back into the script so that next time the script will run without assistance. Again, sometimes this happens and sometimes it doesn't, depending upon the context. (If all this inconsistency seems confusing and annoying, that's because it is.)
A run-only script obviously presents a special case, because it can't be modified. Thus, if a run-only script, while executing, encounters a reference to a targeted application that AppleScript can't locate on its own, then even if the dialog asking for the application appears, and even if the user can locate the application (in which case the script will then continue executing), this information cannot be saved back into the script; the next time the script runs, the dialog will appear again.
Application Missing When an Applet Launches
An applet contains a compiled script, and when the applet is launched, the compiled script runs without