Apple event
Apple events are the message-based
The starting point is a dynamically-typed, extensible descriptor format called an AEDesc, which is just an
inte indicates that the data was a four-byte signed integer in big-endianBesides predefined type codes for various common simple types, there are two predefined structured descriptor types: an AERecord, which has data type reco (record), and AEList with type list (list or array). The internal structure of these contain recursively-nested AEDescs, while the AERecord also associates each element with a unique record field ID, which is an OSType. The Apple Event Manager provides
The Apple Event Manager also supports coercions, which converts AEDescs from one data type to another. In addition to standard coercions, for instance between integer and real types, applications can install their own coercion handler
An Apple event proper is an AERecord with fields that depended on the purpose of the event. In addition, it has attributes (which are distinct from record fields, which are now called the parameters of the event) from a set predefined by the Apple Event Manager. These specify what the event is supposed to do (through event class and event ID), the target address to which the event is to be sent (which could be a process on the local or a remote machine), and various other options for handling it. Remote machines initially had to be connected via
After sending an Apple event to its target process, the sending process can elect to receive a reply to an Apple event. This can contain various bits of information returned from the target about the processing of the original event, including an error code indicating success/failure, any information requested by the original event, and/or other appropriate information.
Apple events are the foundation of the
Object Model
The AppleEvent Object Model (AEOM) was a set of protocols built on top of
The AEOM provided a syntactic layer under which any application could publish its internal objects, allowing those objects to be manipulated in a standardized way. Unlike other similar-sounding concepts such as ToolTalk, there was a clear, orthogonal distinction between nouns and verbs; thus, instead of providing separate commands for "close document" and "close window", there was a single "close" verb which could take references to "document" or "window" objects, or any other object that the application published.
The objects that an application made available through its AEOM support were arranged in a hierarchy. At the top was the application itself, referenced via a null object descriptor. Other objects were referenced by (recursively) specifying their parent object, together with other information identifying it as a child of that parent, all collected in an
Each object could have elements and properties; elements were other objects, which might be created or deleted, while properties could not be created or deleted but had values which might be interrogated or changed. For instance, the application might have one or more window elements representing windows showing the contents of currently-open documents. These windows might have properties such as their title, position and size.
An application could define custom verbs for operating on its objects. The AEOM also specified various standard verbs which (it was hoped) applications would implement in a consistent fashion, such as open, close, create element, delete, set data, and get data. Each verb was defined as an AppleEvent of a specific type and class, together with particular parameters of particular types that were expected to be present. For instance, the "get data" event was the standard means for obtaining the value of a property: it took essentially one parameter, which was an object descriptor identifying the property to be queried. The value of that property would be returned in the reply event. The "set data" event took two parameters, the object descriptor for the property to set and the new value for the property; the reply event was only expected to return a success status or failure error code.
The entire AppleEvent architecture identifies things using four-byte
For instance, consider the following AppleScript sequence controlling a fictional drawing application:
tell application "ScriptableDraw"
set background color of window "New Drawing" to background color of window "Old Drawing"
end tell
This actually involves the sending of two AppleEvents to the target application (and the receipt of their corresponding replies): first, a get-data event is sent to retrieve the background color property of the window identified by the name "Old Drawing"; then a set-data event is sent to apply the value returned as the background color property of the window named "New Drawing".
Since this sort of access pattern was typical, AppleScript made widespread use of the tell statement, which switched the context to the named object in a fashion similar to the with statement found in
tell to the corresponding end tell would be sent to the object named in the tell, instead of the default object, which was the current application.
Object descriptors allowed the identification of objects in various ways. The most interesting one was using a where-clause (which translated into AppleScript terminology as a filter expression). For instance, the AppleScript 1.0 SDK shipped with the source code for an example application called the Scriptable Text Editor, which would respond to scripts such as:
tell application "Scriptable Text Editor"
tell window "Example Document"
set text style of every word whose length > 7 to bold
end tell
end tell
Even today, it is rare to find this kind of power in general-purpose scripting languages outside of SQL.
Adding support for the AEOM in the
Apple did attempt to address this problem with the introduction of various object "suites", which represented standard objects and verbs that were expected to be supported by different types of applications. For instance, all applications were expected to support the "core suite", and any application editing text was expected to support the "text suite". By selecting a suitable set of suites, the developer could at least reduce the workload of planning how to expose their objects. Yet because these objects were generally not part of the system itself (with the exception of the severely limited TextEdit editor), the actual implementation was left to the developer.
Applications developed in
While Cocoa applications are not AEOM based, and often use subtly different objects than Apple's originally defined standard objects, Cocoa apps are generally much more scriptable than their "classic" counterparts—in fact, it is uncommon to find a Cocoa application that is not scriptable to some degree.
Scripting Bridge
The Scripting Bridge is a macOS framework which allows applications to communicate with each other without the use of an intermediary scripting language such as AppleScript. Like AppleScript, the Scripting Bridge uses Apple events for inter-application communication.[1]
The Scripting Bridge is typically used from Objective-C,[1] but can be used in other programming languages through an Objective-C bridge such as MacRuby[2] and PyObjC.
Further reading
- ). In particular, see Section 2.3 “Apple Events” (pages 9–13), though the history and importance of Apple Events is also discussed elsewhere in the paper.
References
- ^ a b "Scripting Bridge". Apple Developer documentation. Retrieved 2023-02-04.
- ^ Paul, Ryan (2011-09-27). "Tutorial: OS X automation with MacRuby and the Scripting Bridge". Ars Technica. Retrieved 2023-02-04.