AppleScript_ The Definitive Guide - Matt Neuburg [25]
This problem washes over into AppleScript, and is in fact one of the single greatest challenges facing the AppleScript programmer. It would be an exaggeration to claim that the AppleScript language is different with respect to every scriptable application—it's the vocabulary that changes, while the underlying language remains the same—but certainly a programmer trying to drive a particular target application for the first time often feels that all previous experience has suddenly been made irrelevant. (For a vivid account of a real-life user struggling with this challenge, see Appendix A.)
The knowledge of what Apple events a scriptable application can respond to, and what it will do in response to them, is an implicit fact built into its workings, not an explicit fact written somehow on its face. How, then, is it possible to know what a scriptable application's repertory is? Some secondary document is clearly needed to expose this information. In the AppleScript world, this document is the application's dictionary, a resource built in to the application for the specific purpose of describing its repertory. There is a section about dictionaries later in this chapter, and an entire chapter devoted to them later in the book (Chapter 20).
The Life of an Apple Event
There's obviously more to the story of interapplication communication than just the sender application and the target application. For example, earlier it was said that the sender normally receives a reply even if the target isn't even listening. How is this possible? It's possible because the system itself functions as the intermediary through which all interapplication communications happen. The sender doesn't speak directly to the target, but to the system. It is the system that is responsible for passing the message on to the target, and for letting the sender know how things went.
Figure 3-1 shows in more detail the process whereby an Apple event is sent and a reply is returned.
The sender application (at the left of the figure) constructs the Apple event. The Apple event is rather like a letter inside an envelope that you post in the mail. It has information about how it is to be directed—who the target application is, and whether the sender intends to wait around for the reply, and if so, what the timeout value is. This information is intended for the system, and is rather like the stuff that goes on the outside of the envelope. Then there is the content—the details as to what kind of Apple event this is and the particular data that it involves. This information is intended for the target application, and is rather like the letter inside the envelope.
Figure 3-1. Life of an Apple event
The sender application calls the system (in the middle of the figure) and hands it the Apple event . The system, rather like the postal service, examines the Apple event and looks at the information about how it is to be directed. Using this information, the system tries to locate the target application. Let's presume that it succeeds in doing this.
The target application (at the right of the figure) is portrayed as having a repertory of Apple events to which it is prepared to respond. These Apple events are listed using pairs of four-letter codes. (Apple events really are identified by pairs of four-letter codes, and the Apple events shown in the diagram are genuine, common Apple events.)
The system contacts the target application, handing it the Apple event supplied by the sender. The system also attaches to this Apple event a reply Apple event. It is rather as if, when the post office delivers a letter to you, it were to