AppleScript_ The Definitive Guide - Matt Neuburg [158]
To illustrate, we'll command the Finder to perform an operation so long that without a timeout specification, it probably wouldn't have time to reply—we'll ask it to cycle down the entire hierarchy looking for a certain kind of file:
with timeout of 100000 seconds
tell application "Finder"
get every application file of entire contents ¬
of disk 1 where its creator type is "aplt"
end tell
end timeout
If we don't provide a timeout block, this code will time out before the Finder is finished, and we'll get an error: "Finder got an error: AppleEvent timed out ." (Even if the Apple event times out, the Finder will still be cycling down the entire hierarchy, and it will keep doing so until it finishes. So don't run that example unless you're not planning on using the Finder for a while!)
Transaction
A problem that can arise with interapplication communications is that a target application is promiscuous. While you're being a sender and talking to a target application, some other sender can come along and talk to it as well. If this happens in the middle of a series of Apple events from you, it can alter the state of the target application, messing up what you're trying to accomplish.
The Apple event solution to this is the transaction . A transaction is a kind of permission slip allowing you to unify multiple commands. You start by asking for this permission slip, and the target application returns a transaction ID of some sort. You then continue sending the target application Apple events, showing it the transaction ID every time. When you're done, you tell the target that you're done (showing it the transaction ID, of course), and that transaction comes to an end. Not every scriptable application implements transactions (would that they did); a commonly used application that does is FileMaker Pro.
The target application itself is responsible for deciding how to implement the notion of a transaction. All you care about is that state should be conserved throughout the multiple commands of a single transaction. FileMaker's approach is to implement a transaction as monopolization; once you've asked for the permission slip and obtained the transaction ID, FileMaker will simply refuse to respond to any Apple event that does not show the transaction ID until you tell it the transaction is over, at which point it returns to its normal state of promiscuity.
The way to obtain, show, and release the transaction ID is by wrapping your transactional communications in a transaction block , which looks like this:
with transaction
-- transactional code
end transaction
All the actual business of dealing with the transaction ID is handled transparently for you. The with transaction line causes an Apple event to be sent to the current target asking for the transaction ID. Then all the application-targeted Apple events inside the block are accompanied by this transaction ID. Finally, the end transaction line sends the current target an Apple event (accompanied by the transaction ID) telling it to leave transaction mode.
In this example, we monopolize FileMaker Pro long enough to create a Find request and perform it:
tell application "FileMaker Pro"
with transaction
tell database 1
show every record
set f to create new request
set cell "lastname" of f to "neuburg"
find
end tell
end transaction
end tell
There is one important thing to notice about that code: the transaction block is inside the tell block. It is essential to structure your code this way; the application with which you want to carry on a transaction must be the target when the with transaction line is encountered, so that AppleScript knows where to send that first Apple event asking for the transaction ID. Unfortunately, this means we run smack into a bizarre terminology problem. It turns out that FileMaker Pro's dictionary also implements the