---

The Event Model

In most cases, you can simply write your event handlers and not worry about the details of how events are propagated to your application. However, if you have more sophisticated needs, understanding the event model will make it easier to write your code.

Figure 1-3 diagrams the basic Carbon event model in Mac OS X.

User events of all kinds are propagated through the kernel to the Window Server. From there, events are sent to your application in a two-step process:

1. A low-level event loop extracts the events that are relevant to your application and places them into the application’s event queue. This loop also fires timers as necessary. If neither of these tasks need attention, the loop is blocked.

2. The Carbon Event Manager removes events from the event queue and dispatches them to the appropriate event targets. If the target has registered for the event, the appropriate handler is called. If not, the event propagates up the containment hierarchy until someone handles the event.

3. If no registered handler takes the event, and no standard handlers are installed, the event is discarded (unless WaitNextEvent is also installed; see “Carbon Events Versus WaitNextEvent” for more details).

The standard Carbon Event Manager event loop function, RunApplicationEventLoop, automatically handles all of the above operations for you. However, if you want more control over the event-handling mechanism, you may choose to call lower-level functions to explicitly run the event loop and dispatch events. For more information about processing events yourself, see “Processing Events Manually.”

If you create preemptive threads (using Multiprocessing Services), these will have their own low-level event loops and event queues, but they do not receive user events. Cooperatively-scheduled threads (such as you would create with the Thread Manager) share the main application event loop and queue. For more information about processing events in other threads, see “Carbon Events in Multiple Threads.”

---