You have read about Apple events, which are action words or verbs (activate, delete). Apple event classes (and the objects that are based on those classes) are the nouns that your script might want to manipulate in some manner (see Table 1-1). Example 1-2 told the Finder to open a file object (basically, a file on the desktop). Objects are the data or “things” that you are interested in querying or changing when you send an Apple event to a program.
For example, a script that controls a database program usually deals with database, field, record, or cell objects. An AppleScript that sends commands to a text editor works with character, word, paragraph, and document objects.
These Apple event objects are based on classes or blueprints, such as
the file class or the database
class. Table 1-3 shows some of the Apple event
classes from the Apple Event Registry. The operating system
represents these classes internally as four-character codes.
|
Class |
Four-Character Code |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A class is a blueprint or data type for a noun or object that you can manipulate with a script.
When an architect creates a blueprint for a structure, all the homes
that are subsequently built off of the blueprint are the offspring of
her original design. The real wooden, brick, or metallic homes are
“instances” (in object-oriented
parlance) or objects of the blueprint or class.
The architect creates a home class in her
blueprint, then the builders generate real home objects based on the
original class. For example, the BBEdit text editor defines a
word class, which is a bunch of characters that
are unbroken by a space, tab, or new-line character (e.g.,
“apple”). The five characters that
make up the word (a,p,p,l,e) are all objects based on the BBEdit
character class. So a word
object constitutes a group of character objects. If you grouped
together several separate character objects they might look like
(“a”,
“p”,
“p”,
“l”,
“e”).
For example, when you get the Finder to open a folder with a phrase like:
open folder "my_folder"
then you are telling the Finder to open the folder object (based on the folder class) whose name is “my_folder.” This line of code will specifically create a Finder window showing the contents of the folder called “my_folder.”
It is always important to describe an Apple event object in your script by its containment hierarchy, which is an exact specification of where an application like the Finder can find the object. Apple event objects are located in a similar manner to taking apart one of those wooden Russian dolls, where the dolls get smaller and smaller until you finally locate the last solid peanut-shaped doll inside of all the bigger ones. In other words, if you wanted to get information about the sender of the first message in your Outlook Express inbox folder, then you couldn’t just tell Outlook to:
get the sender of the first message
because the emailer would not know where to look (i.e., in the “inbox” folder) for the email message. Consider Example 1-5, which incompletely describes the containment hierarchy for a file (assuming that the file is not located on the desktop).
tell application "Finder" open file "taxes2000" end tell
The Finder cannot find this file because the script does not give a complete container reference, as in:
open file "taxes2000" of folder "Taxes" of startup disk
The script will therefore produce a dialog box reporting an error if it is run.
AppleScript has a number of ways to express containment relationships.
file "taxes2000" of folder "Taxes" of startup disk
(an “inside-out” reference). This is like describing the smallest Russian doll as “the tiny doll inside the slightly bigger doll that is contained by all the larger dolls.” Or, you can use a possessive form such as:
startup disk's (folder "Taxes"'s file "taxes2000")
Using the possessive style with long container references like this one is usually less readable than the inside-out method.