Section 19.6. ConsideringIgnoring

19.6. 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.

19.6.1. 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.

19.6.2. 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 of the same letter are taken to be equivalent. Ignored by default.

diacriticals

If ignored, variants of the same letter with different accent marks (or no accent mark) are taken to be equivalent. Considered by default.

expansion

If ignored, ligatures are taken to be equivalent to their component characters. Considered by default.

hyphens

If ignored, hyphens are taken not to exist. Considered by default.

punctuation

If ignored, word-boundary punctuation and quotation marks and apostrophes are taken not to exist. Considered by default.

white space

If ignored, spaces, tabs, and line-break characters are taken not to exist. Considered by default.

numeric strings

(New in Tiger.) If considered, the string is treated as a version number, consisting of sections delimited by a period; order is determined by successive numeric comparison of these sections.

Here's the syntax for writing a string consideration:

 considering | ignoring considerations [but ignoring | considering considerations]     -- code end considering | ignoring

Each set of considerations is any number of string considerations separated by comma; AppleScript will rewrite the last comma as and. Entire string consideration blocks may also be nested. So, for example:

 ignoring hyphens, expansion and punctuation     considering white space but ignoring case and diacriticals         "a-" = "Å!" -- true     end considering end ignoring

String considerations are Unicode-savvy:

 set bigEpsilon to «data utxt0395» as Unicode text set littleEpsilon to «data utxt03B5» as Unicode text ignoring case     bigEpsilon = littleEpsilon -- true end ignoring

Here's an example illustrating the new numeric strings consideration:

 "1.10" > "1.9.3" -- false considering numeric strings     "1.10" > "1.9.3" -- true end considering

In the comparison inside the considering block, 1 is equal to 1 so we proceed to the next section; 10 is greater than 9 so that's the result of the comparison.