MACINTOSH C CARBON: A Hobbyist's Guide To Programming the Macintosh in C
Version 1.0
© 2001 K. J. Bricknell
CHAPTER 17
THE CARBON EVENT MODEL
Overview
The Carbon Event Model
The Carbon event model, which was introduced with Carbon as an alternative to what is now termed the Classic event model, reduces the amount of events-related code required by an application and, in addition, facilitates a more efficient allocation of processing time on the preemptive multitasking Mac OS X. Indeed, the Carbon event model is the underlying event model on Mac OS X, the Classic event model being constructed on top of this model and emulated by the Carbon Event Manager.
Event Handling Basics
As will by now be apparent, applications using the Classic event model spend a large amount of time in the WaitNextEvent loop handling such user-interface events as mouse-downs and key-downs. In the Carbon event model, this continual and inefficient "polling" for events is avoided, events being dispatched directly to Toolbox objects.
Standard Event Handlers
These dispatched events may be handled automatically by standard event handlers provided by the Carbon Event Manager if you so specify. The provision of standard event handlers greatly simplifies the programming task. As an example, and as will be seen in the demonstration program CarbonEvents1, your application requires no code at all to handle basic window dragging, resizing, zooming, activation, and deactivation operations.
Standard event handlers are provided for each type of event target (windows, menus, controls, and the application itself).
Overriding and Complementing the Standard Handlers
At the same time, you can override or complement the default behavior provided by the standard event handlers by writing your own handlers and installing them on the relevant objects. Your application's event handler will override the standard event handler if it returns noErr, which defeats the event being passed to the standard handler. Your application's event handler will complement the standard event handler if it returns eventNotHandledErr, which causes the event to be further propagated to the standard event handler following handling by your application's event handler. (Event handlers are installed on a stack, the most recently installed on top. The most recently installed handler is called first.)
The Basic Approach
The basic approach to using the Carbon event model API is thus to install the relevant standard event handlers first and then register the types of events your application wishes to receive in order to override or complement the actions of the standard handlers.
Event Propagation Order
Events are propagated in a particular order, that order depending on the type of event. For example, control-related events are sent first to the control, then to the owning window, and then to the application. This means that you can install a handler for the control on either the control, the owning window (as in the demonstration program CarbonEvents1), or the application.
As another example, menu-related events are sent first to the menu, then to the user focus target (that is, the object with current keyboard focus, which can be either a window or a control), then to the application.
RunApplicationEventLoop
At the point where a Classic event model version of your application would call WaitNextEvent, your Carbon event model application calls the Carbon Event Manager function RunApplicationEventLoop. RunApplicationEventLoop:
- Moves events from lower-level OS queues into the Carbon queue.
- Dispatches those events from the Carbon queue to the standard event handlers and, for events types that your application has registered, to your application's event handlers.
When an event occurs that requires your program's attention, the Carbon Event Manager calls the handler for that event type. On return from the handler, your program is suspended until the next event requiring its attention is received. Thus your program only uses processor time when processing an event, other programs and processes running in the meantime.
Event Timers
The Carbon Event Manager supports the installation of timers, which can be set to fire either once or repeatedly, and which may be used to trigger calls to a specified function at a specified elapsed time or at specified intervals.
Event Reference, Class, and Type
Event Reference
The event reference is the core Carbon Event Manager data structure:
typedef struct OpaqueEventRef *EventRef;
Event Class and Type
As was stated at Chapter 2, the Classic event model is limited to a maximum of 16 event types. By contrast, the Carbon event model can accommodate an unlimited number of event types. Event types are grouped by event class.
Typical event classes, as represented by constants in CarbonEvents.h, are as follows:
kEventClassApplication
kEventClassWindow
kEventClassControl
kEventClassMenu
Each event class comprises a number of event types. For example, some of the many event types pertaining to the kEventClassWindow event class, as represented by constants in CarbonEvents.h, are as follows:
kEventWindowDrawContent
kEventWindowActivated
kEventWindowClickDragRgn
kEventWindowGetIdealSize
Given an event reference, your application can ascertain the class and type of a received event by calling GetEventClass and GetEventKind.
Standard Event Handlers
Standard Application Event Handler
The standard application event handler is installed automatically when your application calls RunApplicationEventLoop. Amongst other things, the standard application event handler handles application-activated and application-deactivated events (in Classic event model parlance, resume and suspend events).
Standard Window Event Handler
The standard window event handler handles all of the possible user inter-actions with a window (dragging, resizing, zooming, activation, deactivation, etc.). It must be explicitly installed on the target window by your application. You can cause the standard window event handler to be installed on a window as follows:
- For a window created from a 'WIND' resource using GetNewCWindow, either set the standard handler attribute in a call to the function ChangeWindowAttributes, for example:
ChangeWindowAttributes(windowRef,kWindowStandardHandlerAttribute,0);
or call InstallStandardEventHandler, passing in an event target reference (type EventTargetRef) obtained using GetWindowEventTarget, for example:
InstallStandardEventHandler(GetWindowEventTarget(windowRef));
- For a window created using CreateNewWindow, pass kWindowStandardHandlerAttribute in the attributes parameter.
The Application's Event Handlers
Handlers are Callback Functions
The handlers provided by your application are callback functions. When called, they are passed:
- A reference to the event handler call (type EventHandlerCallRef).
- The event reference, from which you can extract the event class and type.
- A pointer to user data ( assuming that you passed a pointer to that data when you installed the handler).
Installing the Application's Event Handlers
You can install handlers provided by your application using InstallEventHandler:
OSStatus InstallEventHandler(EventTargetRef inTarget,EventHandlerUPP inHandler,
UInt32 inNumTypes,const EventTypeSpec *inList,
void *inUserData,EventHandlerRef *outRef);
|
| inTarget |
An event target reference to the target the handler is to be registered with. Use one of the following functions to obtain this reference:
GetApplicationEventTarget
GetWindowEventTarget
GetControlEventTarget
GetMenuEventTarget
GetUserFocusEventTarget
|
| inHandler |
A universal procedure pointer to the handler function provided by your application. |
| inNumTypes |
The number of event types to be registered by this call to InstallEventHandler. |
| inList |
A pointer to an array of type EventTypeSpec structures specifying the event types being registered. The EventTypeSpec structure is as follows:
struct EventTypeSpec
{
UInt32 eventClass; // Event class
UInt32 eventKind; // Event type
};
typedef struct EventTypeSpec EventTypeSpec;
For example, if you wished to register the kEventWindowDrawContent and kEventWindowActivated event types, you would define the array as follows:
EventTypeSpec myTypes[] = { { kEventClassWindow, kEventWindowDrawContent },
{ kEventClassWindow, kEventWindowActivated } }; |
| inUserData |
Optionally, a pointer to data to be passed to your event handler when it is called. |
| outRef |
If you will later need to remove the handler, pass a pointer to a variable of type EventHandlerRef in this parameter. On return, this variable will receive the event handler reference that will be required by your call to RemoveEventHandler. |
You can also use the following macros, which are derived from the function InstallEventHandler, to install your application's handlers:
InstallApplicationEventHandler
InstallWindowEventHandler
InstallControlEventHandler
InstallMenuEventHandler
Different object of the same type do not have to have the same handler. For example, you can install separate handlers on each of two windows.
Inside The Application's Event Handlers
Getting Event Parameters
In some circumstances, in order to correctly handle a particular event type, you may need to extract specific data from the event using the function GetEventParameter. For example, on receipt of an event in the kEventClassWindow class, you will almost invariably need to call GetEventParameter to get the window reference required to facilitate the handling of certain event types in that class. Similarly, on receipt of an event of type kEventMouseDown, you might need to call GetEventParameter to obtain the mouse location.
The GetEventParameter prototype is as follows:
OSStatus GetEventParameter(EventRef inEvent,EventParamName inName,
EventParamType inDesiredType,EventParamType *outActualType,
UInt32 inBufferSize,UInt32 *outActualSize,void *outData);
|
| inEvent |
A reference to the event. |
| inName |
The parameter's symbolic name. Symbolic names pertaining to the various event types are listed in CarbonEvents.h immediately after the enumerations for those types. For example, the symbolic name for the mouse location is kEventParamMouseLocation. |
| inDesiredType |
The type of data. This is listed against the parameter's symbolic name in CarbonEvents.h. For example, the type of data pertaining to the symbolic name kEventParamMouseLocation is typeQDPoint. |
| outActualType |
Actual type of value returned. Specify NULL if this information is not needed. |
| inBufferSize |
The size of the output buffer. |
| outActualSize |
Actual size of value returned.Specify NULL if this information is not needed. |
| outData |
A pointer to the buffer which will receive the parameter data. |
The types of data that can be extracted from an event depends on the type of event. The parameter symbolic names and data types listed in CarbonEvents.h together indicate the type, or types, of data obtainable from an event of a particular type.
Event Parameters and Command Events
The Carbon Event Manager can associate special command events with menu items with command IDs. You can, of course, assign your own command IDs to menu items using SetMenuItemCommandID; however, note that CarbonEvents.h defines command IDs for many common menu items, for example:
kHICommandQuit = FOUR_CHAR_CODE('quit')
kHICommandUndo = FOUR_CHAR_CODE('undo')
kHICommandCut = FOUR_CHAR_CODE('cut ')
kHICommandPaste = FOUR_CHAR_CODE('past')
When a menu item with a command ID is chosen by the user, either with the mouse or using a Command-key equivalent, the Carbon Event Manager dispatches the relevant command event (class kEventClassCommand, type kEventProcessCommand).
When your application's handler receives a kEventProcessCommand event type, you pass kEventParamDirectObject in the inName parameter of your GetEventParameter call, typeHICommand in the inDesiredType parameter, and the address of a structure of type HICommand in the outData parameter. The HICommand structure is as follows:
struct HICommand
{
UInt32 attributes;
UInt32 commandID;
struct
{
MenuRef menuRef;
UInt16 menuItemIndex;
} menu;
};
typedef struct HICommand HICommand;
Thus you will be able to extract the menu reference and menu item number, as well as the command ID of the chosen menu item (if any), from the data returned by the call to GetEventParameter.
Quit Command Handling
The Quit command event is a special case. When the Quit item is chosen, the standard application event handler calls either the default Quit Application Apple event handler or your application's Quit Application Apple event handler if it has installed its own. (When your application calls RunApplicationEventLoop, the default Quit Application Apple event handler is automatically installed if the application has not installed its own.)
Thus the only action required by your application's handler is to ensure that it returns eventNotHandledErr when it determines that the commandID field of the HICommand structure contains kHICommandQuit, thereby causing the event to be propagated to the standard application event handler and thence to the relevant Quit Application Apple event handler.
For this to work on Mac OS 8/9, your application must assign the command ID kHICommandQuit to the Quit item at program start when the application determines that it is running on Mac OS 8/9.
Setting Event Parameters
In certain circumstances, your handler will need to call SetEventParameter to set a piece of data for a given event. For example, suppose you wish to constrain window resizing to a specified minimum size and, accordingly, register for the kEventWindowGetMinimumSize event type. When this event type is received by your handler (it will be dispatched when a mouse-down occurs in the size box/resize control of a window on which your handler is installed), your handler should call SetEventParameter with kEventParamDimensions passed in the inName parameter and a pointer to a variable of type Point passed in the inDataPtr parameter. (The Point variable should contain the desired minimum window height and width.)
Converting an Event Reference to an Event Record
In certain circumstances, your handler may need to convert the event reference to a Classic event model event structure (type EventRecord) in order to be able to handle the event. You can use the function ConvertEventRefToEventRecord for that purpose.
Menu Adjustment
You can ensure that your application's menu adjustment function is called when appropriate by registering the kEventMenuEnableItems event type (kEventClassMenu event class) and calling your menu adjustment function when that event type is received. The kEventMenuEnableItems event type will be dispatched when a mouse-down occurs in the menu bar and when a menu-related Command-key equivalent is pressed.
Cursor Shape Changing
In Classic event model applications, the application's cursor shape-changing function is typically called when mouse-moved Operating System events are received. An alternative "trigger" is required when using the Carbon event model.
One approach is to install a Carbon events timer set to fire at an appropriate interval and call the cursor shape-changing function when the timer fires. However, this method is not recommended for Mac OS X because it is somewhat like polling for an event, which is more processor-intensive.
The recommended approach is to register for the kEventMouseMoved event type (kEventClassMouse event class) and call the cursor shape-changing function on receipt of that event type.
Window Updating
To accommodate window content region updating (re-drawing) requirements, your application should register for the kEventWindowDrawContent event type (kEventClassWindow event class) and call its update function when that event type is received.
Note that the Window Manager sends an event of type kEventWindowUpdate to all windows that need updating, regardless of whether those windows have the standard window event handler installed or not. If the standard window event handler is installed, then when the standard handler receives the kEventWindowUpdate event, it calls BeginUpdate, sends a kEventWindowDrawContent event, and calls EndUpdate. There is thus no need for your update function to call BeginUpdate and EndUpdate when responding to kEventWindowDrawContent events.
Handler Disposal
All handlers on a target are automatically disposed of when the target is disposed of.
Sending and Explicitly Propagating Events
Sending Events
You can send an event to a specified event target using either the function SendEventToEventTarget or the following macros derived from that function:
SendEventToApplication
SendEventToWindow
SendEventToControl
SendEventToMenu
SendEventToUserFocus
Explicitly Propagating Events
You can explicitly propagate an event up the propagation chain by calling CallNextEventHandler within your event handler. This is useful in circumstances where, for example, you wish to incorporate the standard handler's response into your own pre- or post-processing.
Event Timers
Event timers may be used for many purposes, the most common one being to trigger a call to your application's idle function, perhaps for the purpose of blinking the insertion point caret. You can use InstallEventLoopTimer to install an event timer:
OSStatus InstallEventLoopTimer(EventLoopRef inEventLoop,EventTimerInterval inFireDelay,
EventTimerInterval inInterval,
EventLoopTimerUPP inTimerProc, void *inTimerData,
EventLoopTimerRef *outTimer);
|
| inEventLoop |
The event loop on which the timer is to be installed. Usually, this will be the event loop reference returned by a call to GetCurrentEventLoop. |
| inFireDelay |
The required delay before the timer first fires. This can be 0. |
| inInterval |
A value of type double specifying the interval at which the timer is required to fire. For one-shot timers, 0 should be passed in this parameter. For a timer whose purpose is to trigger calls to an idle function which blinks the insertion point caret, pass the value returned by a call to GetCaretTime converted to event time by the macro TicksToEventTime.
Note that event time is in seconds since system startup. You can use the macros TicksToEventTime and EventTimeToTicks to convert between ticks and event time. |
| inTimerProc |
A universal procedure pointer to the function to be called when the timer fires. |
| inTimerData |
Optionally, a pointer to data to be passed to the function called when the timer fires. |
| OutTimer |
A reference to the newly-installed timer. Usually, this will be required only if you intend to remove the timer at some point. |
Note that, depending on the parameters passed to this function, the timer can be set to fire either once or repeatedly at a specified interval.
You can remove an installed timer by calling RemoveEventLoopTimer.
Getting Event Time
Your application can determine the time an event occurred using the function GetEventTime. It can also determine the time from system startup using the function GetCurrentEventTime.
Other Aspects of the Carbon Event Model
The Carbon Event Model and Apple Events
Your application requires no code at all to ensure that, when Apple events are dispatched to it, its Apple event handlers are called.
Carbon Event Model and Control Hierarchies
When you establish an embedding hierarchy for controls, you are also establishing an event handling chain. When you click in a given control, the event is sent first to that control. If that control does not handle the event (that is, its handler returns eventNotHandledErr), the event is passed up the chain to the control that contains the first control, and so on up the chain.
Carbon Event Model and Event Filter Functions
In Classic event model applications, you must pass a universal procedure pointer to an application-defined event filter (callback) function in the modalFilter parameter of ModalDialog, and call your application's window updating function within the filter function.
Calling your window updating function from within your event filter function is not necessary in Carbon event model applications provided the application installs the standard window event handler on the relevant windows, registers for the kEventWindowDrawContent event type, and calls its window updating function when that event type is received.
Mouse Tracking
The demonstration program QuickDraw (Chapter 12) uses the Event Manager function StillDown in the doDrawWithMouse function to determine whether the mouse button has been continuously pressed since the most recent mouseDown event. The Event Manager function WaitMouseUp is often used for similar purposes.
For reasons of efficient use of processor cycles, TrackMouseLocation should be used in lieu of StillDown and WaitMouseUp in applications intended to run on Mac OS X. (TrackMouseLocation does not return control to your application until the mouse is moved or the mouse button is released.) When TrackMouseLocation returns, the outResult parameter contains a value representing the type of mouse activity that occurred (press, release, etc.) and the outPt parameter contains the mouse location.
The function TrackMouseRegion is similar to TrackMouseLocation except that TrackMouseRegion only returns when the mouse enters or exits a specified region.
Alternative for Delay Function on Mac OS X
Programs sometimes call the function Delay to pause program execution for the number of ticks passed in the duration parameter. On Mac OS X, if the delay is more than about two seconds, the cursor will automatically be set to the wait cursor. To avoid this, you can instead call the function RunCurrentEventLoop with the required delay in seconds (perhaps converted from ticks using the macro TicksToEventTime) passed in the inTimeout parameter.
Main Constants, Data Types, and Functions
Constants
Error Codes
eventAlreadyPostedErr = -9860
eventClassInvalidErr = -9862
eventClassIncorrectErr = -9864
eventHandlerAlreadyInstalledErr = -9866
eventInternalErr = -9868
eventKindIncorrectErr = -9869
eventParameterNotFoundErr = -9870
eventNotHandledErr = -9874
eventLoopTimedOutErr = -9875
eventLoopQuitErr = -9876
eventNotInQueueErr = -9877
Event Classes
kEventClassMouse = FOUR_CHAR_CODE('mous')
kEventClassKeyboard = FOUR_CHAR_CODE('keyb')
kEventClassTextInput = FOUR_CHAR_CODE('text')
kEventClassApplication = FOUR_CHAR_CODE('appl')
kEventClassMenu = FOUR_CHAR_CODE('menu')
kEventClassWindow = FOUR_CHAR_CODE('wind')
kEventClassControl = FOUR_CHAR_CODE('cntl')
kEventClassCommand = FOUR_CHAR_CODE('cmds')
Event Types
kEventMouseDown = 1
kEventMouseUp = 2
kEventMouseMoved = 5
kEventMouseDragged = 6
kEventRawKeyDown = 1
kEventRawKeyRepeat = 2
kEventRawKeyUp = 3
kEventRawKeyModifiersChanged = 4
kEventAppActivated = 1
kEventAppDeactivated = 2
kEventAppQuit = 3
kEventAppLaunchNotification = 4
kEventMenuEnableItems = 8
kEventWindowUpdate = 1
kEventWindowDrawContent = 2
kEventWindowActivated = 5
kEventWindowDeactivated = 6
kEventWindowGetClickActivation = 7
kEventWindowShown = 24
kEventWindowHidden = 25
kEventWindowBoundsChanging = 26
kEventWindowBoundsChanged = 27
kEventWindowClickDragRgn = 32
kEventWindowClickResizeRgn = 33
kEventWindowClickCollapseRgn = 34
kEventWindowClickCloseRgn = 35
kEventWindowClickZoomRgn = 36
kEventWindowClickContentRgn = 37
kEventWindowClickProxyIconRgn = 38
kEventControlHit
kEventProcessCommand = 1
HI Commands
kHICommandOK = FOUR_CHAR_CODE('ok ')
kHICommandQuit = FOUR_CHAR_CODE('quit')
kHICommandCancel = FOUR_CHAR_CODE('not!')
kHICommandUndo = FOUR_CHAR_CODE('undo')
kHICommandRedo = FOUR_CHAR_CODE('redo')
kHICommandCut = FOUR_CHAR_CODE('cut ')
kHICommandCopy = FOUR_CHAR_CODE('copy')
kHICommandPaste = FOUR_CHAR_CODE('past')
kHICommandClear = FOUR_CHAR_CODE('clea')
kHICommandSelectAll = FOUR_CHAR_CODE('sall')
kHICommandHide = FOUR_CHAR_CODE('hide')
kHICommandPreferences = FOUR_CHAR_CODE('pref')
kHICommandZoomWindow = FOUR_CHAR_CODE('zoom')
kHICommandMinimizeWindow = FOUR_CHAR_CODE('mini')
kHICommandArrangeInFront = FOUR_CHAR_CODE('frnt')
Mouse Tracking Result
kMouseTrackingMousePressed = 1
kMouseTrackingMouseReleased = 2
kMouseTrackingMouseExited = 3
kMouseTrackingMouseEntered = 4
kMouseTrackingMouseMoved = 5
Data Types
typedef struct OpaqueEventRef *EventRef;
typedef struct OpaqueEventHandlerRef *EventHandlerRef;
typedef struct OpaqueEventHandlerCallRef *EventHandlerCallRef;
typedef struct OpaqueEventLoopRef *EventLoopRef;
typedef double EventTime;
typedef UInt16 MouseTrackingResult;
EventTypeSpec
struct EventTypeSpec
{
UInt32 eventClass;
UInt32 eventKind;
};
typedef struct EventTypeSpec EventTypeSpec;
HICommand
struct HICommand
{
UInt32 attributes;
UInt32 commandID;
struct
{
MenuRef menuRef;
UInt16 menuItemIndex;
} menu;
};
typedef struct HICommand HICommand;
Functions and Macros
Installing and Removing Event Handlers
OSStatus InstallStandardEventHandler(EventTargetRef inTarget);
OSStatus InstallEventHandler(EventTargetRef inTarget,EventHandlerUPP inHandler,
UInt32 inNumTypes,const EventTypeSpec *inList,
void *inUserData,EventHandlerRef *outRef);
#define InstallApplicationEventHandler(h,n,l,u,r) \
InstallEventHandler(GetApplicationEventTarget(),(h),(n),(l),(u),(r))
#define InstallWindowEventHandler(t,h,n,l,u,r) \
InstallEventHandler(GetWindowEventTarget(t),(h),(n),(l),(u),(r))
#define InstallControlEventHandler(t,h,n,l,u,r) \
InstallEventHandler(GetControlEventTarget(t),(h),(n),(l),(u),(r))
#define InstallMenuEventHandler(t,h,n,l,u,r) \
InstallEventHandler(GetMenuEventTarget(t),(h),(n),(l),(u),(r))
OSStatus RemoveEventHandler(EventHandlerRef inHandlerRef);
OSStatus AddEventTypesToHandler(EventHandlerRef inHandlerRef,UInt32 inNumTypes,
const EventTypeSpec *inList);
OSStatus RemoveEventTypesFromHandler(EventHandlerRef inHandlerRef, inNumTypes,
const EventTypeSpec *inList);
Creating and Disposing of Event Handler UPPs
EventHandlerUPP NewEventHandlerUPP(EventHandlerProcPtr userRoutine);
void DisposeEventHandlerUPP(EventHandlerUPP userUPP);
Running and Quitting Application Event Loop
void RunApplicationEventLoop(void);
void QuitApplicationEventLoop(void);
Getting Event Class and Kind
UInt32 GetEventClass(EventRef inEvent);
UInt32 GetEventKind(EventRef inEvent);
Testing for User Cancelled
Boolean IsUserCancelEventRef(EventRef event);
Getting Data From Events
OSStatus GetEventParameter(EventRef inEvent,EventParamName inName,
EventParamType inDesiredType,EventParamType *outActualType,
UInt32 inBufferSize,UInt32 *outActualSize,void *ioBuffer);
Converting an Event Reference to an EventRecord
Boolean ConvertEventRefToEventRecord(EventRef inEvent,EventRecord *outEvent);
Sending Events
OSStatus SendEventToEventTarget(EventRef inEvent,EventTargetRef inTarget);
#define SendEventToApplication(e) \
SendEventToEventTarget((e),GetApplicationEventTarget())
#define SendEventToWindow(e,t) \
SendEventToEventTarget((e),GetWindowEventTarget(t))
#define SendEventToControl(e,t) \
SendEventToEventTarget((e),GetControlEventTarget(t))
#define SendEventToMenu(e,t) \
SendEventToEventTarget((e),GetMenuEventTarget(t))
#define SendEventToUserFocus(e) \
SendEventToEventTarget((e),GetUserFocusEventTarget())
Installing, Resetting, and Removing Timers
OSStatus InstallEventLoopTimer(EventLoopRef inEventLoop, EventTimerInterval inFireDelay,
EventTimerInterval inInterval,
EventLoopTimerUPP inTimerProc,void *inTimerData,
EventLoopTimerRef *outTimer);
OSStatus SetEventLoopTimerNextFireTime(EventLoopTimerRef inTimer,
EventTimerInterval inNextFire);
OSStatus RemoveEventLoopTimer(EventLoopTimerRef inTimer);
Calling Through to Handlers Below Current Handler
OSStatus CallNextEventHandler(EventHandlerCallRef inCallRef,EventRef inEvent);
Getting Event and System Time
EventTime GetEventTime(EventRef inEvent);
EventTime GetCurrentEventTime(void);
Converting Between Ticks and EventTime
#define TicksToEventTime(t) (EventTime) ((t) / 60.0)
#define EventTimeToTicks(t) (UInt32) ((t) * 60)
Mouse Tracking
OSStatus TrackMouseLocation(GrafPtr inPort,Point *outPt,MouseTrackingResult *outResult);
OSStatus TrackMouseRegion(GrafPtr inPort,RgnHandle inRegion,Boolean *ioWasInRgn,
MouseTrackingResult *outResult);
Relevant Window Manager Constants and Functions
Constants
kWindowStandardHandlerAttribute = (1L << 25)
Functions
OSStatus ChangeWindowAttributes(WindowRef window,WindowAttributes setTheseAttributes,
WindowAttributes clearTheseAttributes);
| 
