Your application must be prepared to handle two basic kinds of window-related events in its event loop:
Your application receives mouse-down events if it is the foreground process and the user clicks in the menu bar or a window belonging to your application. When it receives a mouse-down event, your application first calls the FindWindow function to map the cursor location to a window region, and then it branches to one of its own functions. See Responding to Mouse-Down Events for a further discussion of handling mouse-down events under Mac OS 8.5.
Whenever your application is the foreground process, it receives keyboard events. When the user presses a key or a combination of keys, your application responds by inserting data into the document, changing the display, or taking other actions as defined by your application.
Your application activates and deactivates windows in response to activate events, which the Event Manager generates to inform your application that a window is becoming active or inactive. Each activate event specifies the window to be changed and the direction of the change (that is, whether it is to be activated or deactivated).
The Event Manager sends your application an update event when changes on the desktop or in a window require that part or all of a window's content region be updated. The Window Manager and your application can both trigger update events by adding regions that need updating to the update region, as described in the section Maintaining the Update Region .
A switch into or out of your application from a different application is handled through suspend and resume events, not activate events. For example, if the user clicks in a window belonging to another application, the Event Manager typically sends your application a suspend event and performs a major switch to the other application. One of the ways that your application handles a suspend or resume event is by hiding or showing its floating windows; see Responding to Suspend and Resume Events for details.
In addition to handling specific events, however, your application should also call a function in its event loop to synchronize the file data for all of its document windows. While keeping your application's file data synchronized with that of the Finder is a good practice in general, it is especially important if your application is using proxy icons in its document windows. Because a proxy icon is much more prominent to a user than a Finder icon when the user is working in an open document, it is therefore more likely that the user may move the file represented by the proxy icon while the document is open. See Supporting Window Proxy Icons for a sample file synchronization function and a description of other aspects of proxy icon management.