AppleScript_ The Definitive Guide - Matt Neuburg [85]
-- code goes here
end adding folder items to
The event here is called adding folder items to. It takes two parameters: the direct object, and a parameter whose label is after receiving. I've called the direct object ff and the second parameter L, but these handler variable names are up to you.
Similarly, in AppleScript Studio, let's say you want your script to be notified when the user clicks a button in the interface. Then your script will contain an event handler with this structure:
on clicked theObject
-- code goes here
end clicked
That's an event called clicked taking one parameter, the direct object. The name of the direct object in the handler definition, theObject, is up to you.
The syntax of event handlers is possible because the script is compiled in the presence of a dictionary that defines the event. The adding folder items to event is defined in the StandardAdditions scripting addition, and a scripting addition's dictionary is always visible. The clicked event is defined in the AppleScriptKit dictionary ; this dictionary is not always visible, but it is visible when you're editing and compiling AppleScript Studio code.
Interestingly, your code can call an event handler. This is legal (but silly):
on adding folder items to ff after receiving L
display dialog ff & space & L
end adding folder items to
adding folder items to "howdy" after receiving "there"
Most applications that want an entry point to your script do not use event handlers. The reason is that they have no way to make a dictionary visible at the time you're editing and compiling your script. Apple Computer installs the StandardAdditions scripting addition by default on every machine, so it can use this scripting addition to define events used by the System Events application as entry points for folder actions. And AppleScript Studio works in a special way, where the AppleScriptKit dictionary is automatically visible while you're editing your code. But third-party scriptable applications can't make their dictionary automatically visible, and they can't usually expect you to install a scripting addition just in order to be able to use their event handler terminology. Typically they resort to a user handler instead. (See Chapter 26 for examples.)
By the way, built-in AppleScript commands are visible at all times, so you can write event handlers for them. That is how the explicit run handler works (see the next section); for another example, see "Handler Calls, Commands, and Script Objects" in Chapter 8. (The commands get, copy, and set work differently; you can't write handlers for them—the compiler will stop you if you so much as try it.)
The Run Handler
The run handler of a script object (or script) has been discussed in "Code and the Run Handler" in Chapter 6 and "Run Handler" in Chapter 8. The run handler is an event handler. Thus it has event handler syntax; it takes no parentheses, either in the definition or in the call.
It turns out that an explicit run handler may take parameters . This ability is useful only under special circumstances, and in fact it prevents the script object (or script) from running at all under normal circumstances, because you usually have no way to supply these parameters in the call.
The official syntax for defining a run handler with parameters is to express all parameters as a single list. For example:
script s
on run {what, what2}
display dialog what & space & what2
end run
end script
You can't simply tell that script object to run, because you can't supply the parameters. If you try, you'll get an error at runtime:
run s -- error: «script s» doesn't match the parameters {what, what2} for run
One solution is to use the run script command, which permits parameters to be passed to a run handler:
run script s with parameters {"howdy", "there"}
That approach is rather extreme; run script is expensive , because it requires the creation (and destruction) of an entire separate instance of the AppleScript scripting component. A clever and inexpensive