Inside an Apple Event

Here’s how it works when Script Editor compiles and executes the following code, which comprises a complete compilable script:

tell application "Finder" to sleep

This is what happens:

1. The AppleScript component has to find out which Apple event lies behind the sleep command. The component knows that the Finder is one of the places it should look for these details, because the Finder is targeted by the tell statement:

   tell application "Finder"...

2. Remember that sleep is an English-language term for putting the computer to sleep, but it is implemented as the sleep Apple event beneath the surface. Figure 1-4 shows the structure of the sleep Apple event.

   

   Figure 1-4. A sleep Apple event

   The AppleScript component discovers the attributes of the sleep Apple event (e.g., the event id) from a segment of the Finder file called the Apple event terminology extension ('aete') resource. The 'aete' resource maps the sleep script command to the Apple event depicted in Figure 1-4.

3. The component then sends that Apple event to the Finder, which responds to sleep by powering down the computer.

Here is an explanation of the structure behind the Apple event in Figure 1-4.

Every Apple event is comprised of unique four-character codes that represent the:

• Event class

• Event id

• Address of the target application

The event class represents a grouping of similar Apple events. The event id uniquely identifies the Apple event. The target address is a complex data structure that could contain the application’s creator code or its Process Serial Number (PSN) or another piece of identifying information. For example, the sleep Apple event has event class 'fndr' and event id 'slep'. Table 1-2 contains the event classes and event ids for the Standard Suite in the Apple Event Registry. Apple events often get reorganized within different suites when Apple updates its Registry.

Table 1-2. Apple Event Codes for Standard Suite

Event	Event Class	Event Id	Class	Class Id
open	aevt	odoc	application	capp
run	aevt	oapp	document	docu
reopen	aevt	rapp	file	file
print	aevt	pdoc	alias	alis
quit	aevt	quit	selection-object	csel
close	core	clos	window	cwin
count	core	cnte	insertion-point	cins
delete	core	delo
duplicate	core	clon
exist	core	doex
make	core	crel
move	core	move
save	core	save

Most of the time, however, a scripter does not have to deal with event classes and event ids, just their AppleScript language equivalents.

Apple events specify the target programs that should receive the Apple event. Otherwise, your script would cause an execution or runtime error, because the operating system does not know where the Apple event is supposed to go.

The common way to specify the target programs for an Apple event in AppleScript is to use a code such as in Example 1-2. You enclose the Apple events you will send to a program within the tell block, as in Example 1-2, which sends a quit Apple event to “FileMaker Pro”.

Example 1-2. A Script Targeting FileMaker Pro

tell application  "FileMaker Pro"
   quit
end tell

The value of the application signature attribute in Figure 1-4 is also a four-character code (‘MACS' for the Finder), just like the event class and event id. You might recognize this code as the Finder’s creator code.

Tip

Each Macintosh file is distinguished by its file type (for example, a text file has file type "TEXT") and creator code (BBEdit’s is "R*ch"). This is how the operating system knows which program to open when you double-click a desktop file. It examines the file’s creator code.