AppleScript_ The Definitive Guide - Matt Neuburg [164]
try
tell application "Finder"
activate
with timeout of 1 second
display dialog "Press a button." giving up after 2
end timeout
end tell
on error number -1712
activate
display dialog "Ha ha, not fast enough!"
end try
Second-Level Evaluation
By "second-level evaluation " I mean constructing and executing code at runtime. AppleScript has no built-in way of performing second-level evaluation. However, you can achieve much the same effect through the use of the run script scripting addition command, which allows you to compile and run a string. (See "Compiled Script Files as Script Objects" in Chapter 8.)
The use of run script is rather resource-expensive , because it requires that a completely new instance of the AppleScript scripting component be generated and torn down. It's also rather slow, because it takes time to compile the string. Finally, it's rather clunky, because a string run in this way has no communication with its surroundings; indeed, because a new instance of the AppleScript scripting component is generated, it has no surroundings at all. In other words, it isn't like a script object that can "see" globals at the point where it is defined and run.
Nevertheless, there are things you can accomplish with run script that can be accomplished in no other way. For example, all terminology must be resolved at compile time, so the only way to construct completely dynamically, at runtime, a command involving terminology is by means of run script.
In this example, we permit the user to enter part of an expression to be evaluated by saying it to the Finder:
set d to "window 1"
set p to "What Finder object would you like the name of?"
set r to display dialog p default answer d
set s to text returned of r
set s to "tell app \"Finder\" to get name of " & s
try
set res to run script s
display dialog res
on error
display dialog "Sorry, that didn't work."
end try
For another example of run script used for second-level evaluation, see "Record Properties" in Chapter 13.
Part III. AppleScript In Action
Part III is about AppleScript in practice. The previous section described the AppleScript language; that is your sword. Now, wielding this sword, you will go forth to do battle; this section is about the battle—the practical side of actually using AppleScript to get something done.
The chapters are:
Chapter 20, Dictionaries
Chapter 21, Scripting Additions
Chapter 22, Speed
Chapter 23, Scriptable Applications
Chapter 24, Unscriptable Applications
Chapter 25, Unix
Chapter 26, Triggering Scripts Automatically
Chapter 27, Writing Applications
Chapter 20. Dictionaries
In Part II you learned the AppleScript language. It's essential to know this language if you're going to write AppleScript code; yet, ironically, the AppleScript language on its own won't get you very far. That's because AppleScript, all by itself, doesn't do very much; its real power and purpose lies in communicating with scriptable applications, which provide powers that AppleScript lacks. In order that you, the AppleScript programmer, may harness its powers, a scriptable application extends the vocabulary of the AppleScript language. For example, AppleScript can't make a new folder on your hard drive, but the Finder can; therefore the Finder extends AppleScript's vocabulary, supplementing it with terms such as make and folder so that you can use AppleScript to command it (the Finder) to make a folder. This extended vocabulary is called a scriptable application's terminology . A dictionary is the means by which a scriptable application or scripting addition lets the world know how it extends AppleScript's vocabulary.
A dictionary has two audiences—AppleScript and the AppleScript programmer. Let's consider how each of these audiences uses a dictionary:
AppleScript
AppleScript uses an application's dictionary at compile time to look up the terms that the programmer uses. In this way, AppleScript confirms that the terms really exist;