All Databases Inside Mac - Basic Toolbox

suspend event

Operating-System Events

The cooperative multitasking environment allows the Operating System to

communicate information to an application about changes in the operating

status of that application. For example, when your application is switched into

the background, the Operating System sends it a suspend event. Then, when

your application is switched back into the foreground, it receives a resume

event. These types of events are known as operating-system events.

The following figure illustrates how the Event Manager helps provide this

cooperative multitasking environment. The main source of these events is the

Macintosh Operating System itself, which sends suspend, resume, and

mouse-moved events to applications through the Event Manager. (In

system versions earlier than 7.0, these events are sent by MultiFinder.) In

addition to the event queue created by the

Operating System Event Manager, the Event Manager maintains a

separate event queue for each open application. The events in the

Operating System Event Manager queue are always sent to the

foreground application, but other events (for example, update events from the

Window Manager) can be sent to background applications.

Events in a multi-application environment

Because your application might need to execute differently depending on

whether it is running in the foreground or in the background, you can inspect

the low bit of the message field of an operating-system event to determine

whether the event is a suspend or a resume event. For example, if you need to

notify the user of some special occurrence while your application is executing

in the background, you cannot simply put up an alert box. Instead, you should

use the Notification Manager to queue a notification request that will be

presented to the user at the appropriate moment.

When your application receives a suspend event, it does not actually become

inactive until it makes its next request to receive events from the

Event Manager. At the time that it receives the suspend event, your

application can inspect the convertClipboard flag in the message field of the

EventRecord to see whether it should convert any local scrap into the

global scrap. Your application should also hide any floating windows,

selections, and so on. Then you should call WaitNextEvent to relinquish the

processor and allow the Operating System to schedule other processes for

execution. It is important to minimize the processing you do in response to a

suspend event because otherwise the machine may appear sluggish.

When control returns to your application, the first event it receives is a

resume event. Your application may now convert the global scrap back to its

private scrap, if necessary. As part of the resume or suspend event, the

Operating System informs your application if the Clipboard has changed by

setting bit 1 of the message field of the EventRecord.

There are two other kinds of operating-system events, which are

mouse-moved events and application-died event. A mouse-moved event is

sent to an application to indicate that the user has moved the mouse outside of

the region specified to the WaitNextEvent routine. Whenever an application

launched by your application terminates or crashes an application-died event

is sent .

Note: Some early versions of MultiFinder do not send

application-died events, and your application should not depend on

receiving them. These events are provided primarily for use by debuggers.

In System 7.0+, application-died events are now sent as Apple events.

Referenced by (8):