Frontier's support of the Apple Event object model is fully integrated into the UserTalk language.
The object model is the style of interapplication communication promoted by Apple Computer and supported by AppleScript.
Theory of the object model
Common to object model applications are the following characteristics that
determine how they can be scripted:
- They use "object specifiers" to refer to their data;
- They support a proposed set of standard "suites" of verbs;
- They use a proposed set of standard terminology when talking
about their verbs and data.
In the sections below, we discuss how Frontier taps into these common
features to provide a great deal of power in controlling object model
Object Specifier Paths
The most basic aspect of the object model are objects themselves. Objects
are the things that an application operates on, typically its windows,
documents, and the data within them.
Objects can contain other objects - windows can contain text, which might
consist of paragraphs which in turn contain words and characters. This
nesting of objects is known as an application's "containment hierarchy".
Objects fall into two basic categories: elements and properties. Elements
are objects within a container that make up its data - words within a
paragraph or cells within a spreadsheet. Properties are characteristics of
an element that are singular and cannot be deleted - an object's font or
color, or a window's name for example. You can change the value of a
property, but you cannot delete it.
Each Apple Event suite defines a set of objects, their elements and
properties, and the events (verbs) that can be applied to them. An
application is free to expand on these definitions, or to support only a
portion of them. For applications that support the object model, you
should find an outline titled "objectHierarchy" in the application's glue
table (at system.verbs.apps.[appName]) which lists objects with their
elements and properties.
Object specifier paths are UserTalk expressions that refer to an object
or set of objects in an application's containment hierarchy. These
expressions look like Frontier object database paths, but specify a path
into a target application's containment hierarchy, rather than the Frontier
object database hierarchy. The key to differentiating between the two types
of paths is that database paths always begin with a table name, while
object specifier paths begin with a string4 value or another object
In an object specifier path, identifiers followed by an array reference
(square brackets) specify an element, while identifiers not followed by an
array reference specify a property. The expression within an array
reference can be a number or a string, to specify objects by index or name.
It can also be a comparative expression, to specify a "whose" clause - a
set of objects that meet specific criteria. The "to" keyword can be used to
specify a range of indices, or the range between two other objects.
Finally, the array reference expression, or element specifier, can be a
string4 to refer to an absolute or relative position.
Apple Events use string4 values to represent objects. Objects
specifiers constructed with string4s are rather cryptic, so applications
provide "user terms" which are more readable labels for objects.
Frontier's objectModel table contains user terms for a standard set of
objects, such as 'window', 'document', and 'paragraph'. This table also
contains items that refer to a specific types of indexes such as 'last' or
'all'. When writing scripts you will always be able to construct object
specifiers using only user terms and not sting4s.
Applications usually provide additional string4 values and coresponding
user terms for objects specific to that application. For example Eudora
provides string4s with user terms for objects like 'mailbox' and 'message'.
By default, you will find these application specific values in the
application's glue table, but there are times when they will be in a
seperate sub-table (often named "eventInfo") to help keep the main glue
table uncluttered. When this is done a third item in the "with" statement
Here's an example of an object model statement in its simplest form:
If you look in the FileMaker table, you'll see that there's a script named
show, and a string4 named record. As Frontier is evaluating the expression,
it builds an object specifier that indicates record 1. Calling the show
verb causes that record to be displayed.
Here's a richer example:
show (record [cell ["Name"] contains "New"])
This expression walks thru FileMaker's containment hierchy, selecting all
records whose cell "name" contains the sub-string "New".
In both of the previous examples, we only used terminology that's specific
to FileMaker. Other terminology, that all object model applications
support, is stored in the system.macintosh.ObjectModel table. In the
following example we use the term "all" to specify all records, so we must
include the objectModel table in the with statement:
with objectModel, FileMaker
show (record [all])
An index to an object may be a simple number as used in lists (such as
window), a name (window["messages"]), or it can be a more complex
conditional statement as used in the second example. The index can also be
one of several special types. The following list represents several valid
- message[1 to 5] a range
- window[all] every object of a class
- record[cell["name]=="New"] matches a test, can use contains,
The object specifier for a property does not use an index, however
properties are always associated with element objects. Some properties are
read only. You get and set properties much like you manipulate the values
with objectModel, Eudora, eventInfo
with objectModel, Eudora, eventInfo
message.body="Some random text"
Note the inclusion of the eventInfo table, since Eudora keeps object terms
in this subtable.
Addressing Nested Objects
You can also use the with statement to have a set of statements apply to an
object nested in an application's containment hierarchy:
with objectModel, MacWordProcessor, document .word [1 to 4]
set (font, "Palatino")
set (size, 14)
The string4 values "document", "word, "font" and "size" are defined in the
objectModel table. The "set" verb refers to MacWordProcessor.set, and is
applied to the font and size properties of words 1 thru 4 of the frontmost
The best way to learn the objectModel (and UserTalk in general) is to work
through examples for specific applications and experiment.
Thanks to Preston Holmes, email@example.com, for converting this UserLand readme file into HTML.
© Copyright 1996-97 UserLand Software. This page was last built on 5/7/97; 1:41:26 PM.
It was originally posted on 5/9/96; 12:14:48 PM.
Internet service provided by Conxion.