AppleScript_ The Definitive Guide - Matt Neuburg [229]
A hook is a point in an application's operation where it is willing to turn to you—or more exactly, to a script you've supplied—to ask what to do. Many sorts of application use a hook to let you customize their behavior at key moments. Such, for the most part, are the applications listed in "Automatic Location" in Chapter 2. Thus, one example is iCal: as I mentioned a moment ago, when an alarm fires, iCal can run a script in response. Similarly, Apple's Mail program and Microsoft Entourage let you create rules that are performed in response to the arrival of mail messages meeting certain criteria; one of the things a rule can do is to run a script.
Some applications have hooks as their life blood, so to speak. An example is Salling Clicker , which is all about responding to a handheld device (such as a Bluetooth phone) by running a script. Another example is Ovolab Phlink , which answers the phone and turns at every stage of the phone call to your scripts to see what to do—when the phone rings, when it answers, when the caller presses keys on a touchtone phone, when the call ends, and so forth.
Phlink calls into your script by taking advantage of named parameters. For example, when a phone call arrives on your computer, if you have a script called ring in the proper location, it will be called. In order for this to work, your script must contain a handler with this definition:
on incoming_call given call:theCall, ¬
callername:theName, ¬
callerid:theId, ¬
ringcount:theCount
-- code
end incoming_call
This is a user handler; you can define it without any scripting addition because it contains no special terminology. With named parameters, the names are up to you—except that you've purposely used the names that Phlink will use when it calls your script. Phlink does define these handlers in its dictionary, but only for informational purposes; it can't enforce them on your script, because your script isn't targeting Phlink at the point where the handler is defined. A nice thing about this choice of syntax is that you can omit, in your definition, parameters you're not interested in receiving; there is, you remember, no penalty when a handler is called with extra parameters (they are simply ignored; see "Syntax of Defining and Calling a Handler" in Chapter 9).
An application may be considered attachable if it treats ordinary user actions as hooks (see "Modes of Scriptability" in Chapter 3). For example, BBEdit will run scripts located in its Menu Scripts folder, in response to your choosing from any of BBEdit's built-in menus. Thus, any of BBEdit's menus can do what it normally does, but optionally it can include, or can be overridden by, functionality that you provide as a script. Such a script must contain a handler with the following structure:
on menuselect(menuName, itemName)
-- code
end menuselect
The fact that an application can call into a user handler that takes positional parameters in your script is surprising, and involves a cool mechanism under the hood; this same mechanism is also how scriptability is implemented in an applet (see Chapter 27).
An event is observable if another application can see it. So for example QuicKeys , mentioned earlier, can run a script in response to a certain application starting or quitting, or becoming or ceasing to be frontmost, or when a certain drive is mounted or unmounted. That events at a high system level should be observable is not surprising, because it is reasonable that they should be so; an application certainly has a need and a right to know when it becomes frontmost, so why shouldn't it be able to tell when some other application becomes frontmost? On the other hand, the notion that one application can observe what's happening internally within some other application is surprising, both