AppleScript_ The Definitive Guide - Matt Neuburg [157]
using terms from application "Microsoft Entourage"
set n1 to a reference to name of folder 1 of application "Microsoft Entourage"
end using terms from
using terms from application "Finder"
set n2 to a reference to name of folder 1 of application "Finder"
end using terms from
on getThing(R)
return (get contents of R)
end getThing
getThing(n1) -- "Inbox"
getThing(n2) --"Mannie"
A terms block can also be used to solve the puzzle of how an applet can be made to behave like a compiled script file when a targeted application might be missing. (See "Missing External Referents" in Chapter 3.) Normally, an applet attempts to locate all targeted applications at launch time. A compiled script file, on the other hand, postpones this attempt until the script is running and code targeting an application is actually encountered; if such code is never encountered, the question never arises. The problem is to get an applet to behave that way—to launch and start running even if, somewhere in its code, it targets an application that might not be present. The trick here is to refer to the target application in its tell block by means of a variable, wrapping the whole thing in a terms block so that compilation will succeed:
using terms from application "someAppThatMightBeMissing"
set s to "someAppThatMightBeMissing"
tell application s
doYourThing
end tell
end using terms from
If this code is actually encountered during the course of execution, then the application had better be present or there will be a runtime error. But the point is that at least the applet will launch! Other code might decide whether to execute this code, based on the presence of the application or some other criteria, or this code could be enclosed in a try block that will catch the error and proceed in some other way (see "Errors," later in this chapter).
With
A with block is used to specify certain external attributes of Apple events sent to target applications from inside the block. Two types of with block are defined: a timeout block and a transaction block.
Timeout
Recall from "Apple Events" in Chapter 3 that during interapplication communications, the sender of an Apple event may attach to that Apple event a specification of how long it is willing to wait for a reply. This is the Apple event's timeout period. If the target does not reply within the specified timeout period, for whatever reason (the requested operation might be too lengthy, the target application might be otherwise engaged, and so forth), the system stops waiting for a reply and reports to the sender that the Apple event timed out. This report arrives as an error; your script can handle this error and proceed (see "Errors," later in this chapter).
This entire mechanism is valuable, because (among other things) it rescues the sender from hanging indefinitely while waiting for the target to reply; if the target takes too long, the sender is able to proceed nonetheless. Of course, the sender must then do without any reply from the target, but a script can take account of this possibility. For example, reporting the problem to the user and proceeding, or even terminating in good order, is surely preferable to hanging or appearing to hang while waiting for a reply that is taking a long time to arrive and that may, indeed, never come.
All Apple events sent to target applications have a default timeout value of one minute. This is a good compromise between waiting sufficiently long for lengthy operations to complete and waiting so long (or not having any timeout at all) that a script can hang or appear to hang. If this value is acceptable to you, you don't need a timeout block to change it.
To change the timeout value temporarily using a timeout block , use this syntax:
with timeout of integer second[s]
-- code affected by timeout value
end timeout
This affects only code within the block; afterwards, Apple events revert to the default timeout value. To wait indefinitely, use an extremely large integer. The maximum permissible value is 8947848. In