AppleEvents

AppleEvents are one of the lesser-known, but pivotal features in making the MacOS good. Basically, AppleEvents are messages that pass between any apps on the system. Any app can send an AppleEvent to any other app. An AppleEvent consists of a "header", if you will, which is a 4-letter code. Some codes are reserved by the system or conventionally used for a very basic function (i.e., odoc is the code for sending a "Document owned by this app has been launched" message). Some are invented by the application. Each AppleEvent has parameters; a text parameter, a boolean parameter, a file pointer parameter, a Mac data parameter, and so on. The sending app can fill any or all of these parameters with data it wishes to transmit. (The odoc message must always be accompanied by a file parameter, for example)

AppleScript is a user-level medium for directing applications via AppleEvents. It is basically just a frontend to the AppleEvent API. It saves the writer from having to deal with cryptic four letter codes, and allows them to use English-like terms and syntax. However, programmers also have access to this functionality. They must use the API directly to formulate their code, target, and attach their parameters.

AppleEvents are used for basic OS-level functions, too. For example, it is a convention for an application to, when text is dropped on one of its editfields, fill the field with the dropped text. To reiterate, ANY application can transmit text via drag and drop to ANY other application. Try that on Windows sometime.

A good analogy for this is that all the applications know a common language. Even if they've never met before, they can still communicate with one another, on account of knowing this common language. Take ircle, an IRC client with a very robust and well documented implementation of AppleEvents. It allows not only control via AppleEvents, but on the fly compilation of scripts. So, I can write a script to accept / commands on the input line, and use an AppleScript to subsequently control my MP3 player, like that. Or my email program. Or my web browser. Or AIM. Or... you get the idea.

There is, as far as I know, nothing as advanced or seamless as this on any other popular GUI OS.

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.