AppleScript_ The Definitive Guide - Matt Neuburg [159]
You might worry about what happens if something goes wrong in the middle of the transaction block. What if we say something that generates an error? We'll never reach the end of the transaction block, and that means we'll leave FileMaker Pro in a transaction state, refusing to respond to Apple events. You're perfectly right to worry about this; you certainly don't want to leave FileMaker Pro in transaction mode. If FileMaker Pro were to get into such a state, you couldn't even quit it, because the Quit menu item is implemented with an Apple event—and FileMaker Pro won't listen to that Apple event, because it doesn't supply the transaction ID! It turns out, though, that AppleScript solves this problem transparently. If an error is encountered during a transaction block, AppleScript sends the target the Apple event that ends the transaction. I suspect that the transaction block is wrapped in a sort of invisible try block. In any case, it's really all very nicely implemented.
Considering/Ignoring
There are two kinds of considering/ignoring block. One is the "ignoring application responses" block, which affects the nature of Apple events targeting an application. The other affects the details of string comparisons.
Ignoring Application Responses
Recall from "Apple Events" in Chapter 3 that during interapplication communications the sender of an Apple event may specify that it has no intention of waiting around for a reply. It doesn't care what the result is; it doesn't care if there's an error. It just wants to send the Apple event and be done with it, proceeding immediately to its own next step. In AppleScript, here's how to send such an Apple event:
ignoring application responses
-- code
end ignoring
Within the block, only Apple events sent to other applications are affected. Apple events sent to scripting additions, for example, are sent in the normal way and receive whatever replies they normally receive.
For an example, see "Reduction" in Chapter 1. The code that opens a URL from the clipboard is wrapped in an "ignoring application responses" block, because I want the browser or mail client or whatever to open in the background and without my waiting for it; thus I can get on immediately with what I was doing.
Inside an "ignoring application responses" block, it is possible to override the block by embedding a "considering application responses" block. You might use this construct, for example, to ignore responses from one application but not another.
String Considerations
String considerations are optional switches that govern the nature of a string comparison (see "Comparison Operators" and "Containment Operators" in Chapter 15). For example, string comparison may be case-sensitive or case-insensitive. You can use a considering/ignoring block to govern this behavior.
Until recently there was no mechanism for making string considerations visible to a targeted application. This meant that string considerations could operate only within AppleScript; a string comparison performed as part of a boolean test element specifier, for example, could not be affected by string considerations (see "Boolean Test" in Chapter 11 and "Who Performs an Operation" in Chapter 15). This limitation has changed, but applications must be rewritten if they are to notice and take account of string considerations (and I do not know of any application that has been rewritten in this way). See also "String and Clipboard" in Chapter 21 on the offset scripting addition command.
Here are the string considerations:
case
If ignored, uppercase and lowercase variants