AppleScript_ The Definitive Guide - Matt Neuburg [26]
The target application (presuming it is well behaved) responds to whatever the Apple event asks it to do, either doing it successfully or generating an error message; then it puts the result into the reply event. There are two parts to this result. First, the target application must supply a value signifying whether things succeeded. Second, the target application may insert into the reply any other information to be returned. If there was an error, it can insert a message describing the problem; if things succeeded and a result is expected, it can insert that result.
The target application now signs off, and the system is left holding the reply Apple event (of which, as we said, it never let go). The system now delivers the reply Apple event to the sender application, and the story ends.
What an Apple Event Looks Like
An Apple event was never meant for human eyes. It is meant to be machine-constructible and machine-parsable. Nevertheless, it is possible to encode all the facts about an Apple event in a textual format. One commonly used format is called AEPrint . Let's examine an AEPrint representation of a real live Apple event, to get an idea of what a typical Apple event looks like. The Apple event we'll use is a rather elaborate one I mentioned earlier, an Apple event that means: "Look in the mailbox where the incoming mail is, find the first mail message with a subject that starts with the word 'applescript', and move it into the 'AppleScript' mailbox." Example 3-1 displays that Apple event in AEPrint format .
Example 3-1. A raw Apple event
core\move{
insh:insl{
kobj:obj {
form:'name',
want:'Mbox',
seld:"appleScript",
from:'null'( )
},
kpos:'end '
},
----:obj {
form:'indx',
want:'cobj',
seld:1,
from:obj {
form:'test',
want:'msg ',
from:obj {
form:'prop',
want:'prop',
seld:'unBX',
from:'null'( )
},
seld:cmpd{
relo:'bgwt',
obj1:obj {
form:'prop',
want:'prop',
seld:'subj',
from:exmn($$)
},
obj2:"applescript"
}
}
}
}
I don't want to burden you with a full explanation of Example 3-1 (especially since the whole point of AppleScript is that you shouldn't have to worry about what a raw Apple event looks like), but a few characteristic points are of interest.
First, notice the predominance of four-letter codes. Nearly everything seems to consist of exactly four letters: core, move, insh, insl, kobj, form, want, seld, from, prop, kpos, indx, cobj, test, and so forth. Even some things that appear to be only three letters are actually four letters: obj and end and msg, for example, actually have a fourth character (a space).
Tip
These four-letter codes are actually integers. An integer is four bytes, while a character from the ASCII range is one byte, so an integer can express four "packed" characters. The expression of this integer as a four-letter string is simply a convenience for the human reader. The use of single quotes to delimit a four-letter code is a standard convention, and I'll use it in later parts of this book.
Second, observe the overall structure of the Apple event, which is actually quite simple. The command itself is specified in the first line: core\move, exactly as shown in Figure 3-1. Just about every Apple event has at least one parameter, known as the direct object ; this is symbolized by ---- (can you find it?), and this particular Apple event also has a second parameter, symbolized by insh.
Finally, you've probably already spotted the repeating pattern form, want, seld, from, which appears throughout the Apple event. This is how an Apple event specifies an object (such as "the 'AppleScript' mailbox"), something that it very commonly needs to do; we'll talk more about the AppleScript avatar of this pattern later on ("Element Specifiers" in Chapter 11).
Go and Catch an Apple Event
What I did to capture the Apple event displayed in Example 3-1 was to turn on the Apple Event Log in