AppleEvents are amazingly
similar to many other sorts of
event models. They are very similar to the
Windows messaging passing model, but not as "
firm" as Windows (
Windows messaging is more standard, and does not largely
encourage custom messages between
applications). For instance,
Windows uses the
messaging functions internally to a
program, or
externally between programs on the same
machine. This means that whether or not the
window object is in your
process space, you still
message it the same. This seems kind of strange to point out, but it is not as
common (and certainly not required) that
Macintosh programs throw and catch their own
messages to start these
processes.
There are a few advantages to
Apple's system over others:
- AppleEvents are AppleScript - able: This largely applies to the way you write a program, and how you want it used, but you can write a script natively in the AppleScript language to send and receive events (and custom events) through an application's AppleScript Dictionary. This Dictionary is a registry of sorts that lists the applicable event exchanges that can take place. This can be done in Windows through VB's functionality or any other language in which you wish to write a message loop, but it is harder and not as "event-oriented" as in AppleScript.
- AppleEvents were meant to be recordable: Mac OS has a built-in event recording harness, such that to be a good Mac citizen, you need to throw and respond to AppleEvents well. Thus, you can be a recordable app by responding the same way to a series of commands. Many ported applications, such as Macintosh Office have limited AppleScript support, but more native applications (such as Stuffit) are fully AppleScript-able, and play by the rules.
- AppleEvents enforce Apple UI guidelines: AppleEvents are well-planned in that they force application developers to support and adopt many features that are Mac-like. The document-centric nature of many applications are enforced through the handling of as many applicable Apple events as possible. By handling items, such as drag and drop, double click, cut and paste, dragging to trash, etc, it helps conform the applications into Apple's vision for the desktop experience.
In
OS X,
AppleEvents are devaluated in favor of the new event model,
Carbon Events. (Pre
OS X can use this model to a limited extent by using
Carbon Lib). Instead of calling
WaitNextEvent() to see a new
message coming in (and having to behave as a good
process citizen), you can set
handlers for events that fire once an event is processed in the
queue (otherwise the default handler is
called). It makes it easier to use by only "suubscribing" to the events you really want to deal with, and letting the OS handle the rest. Carbon events are very accessible in
AppleScript, and help to take advantage of the new
processing model, the new
waiting model, everything. They are a far
superior choice for the
Macintosh applications of the
future.