Messages

Messages are the mechanism by which windows communicate with one another and are notified of system- or user-initiated events by Presentation Manager. In a typical Presentation Manager application, all interaction between the user and windows, or between one window and another, takes place by way of messages. Messages may be of three types:

User-initiated

Application-initiated System-initiated

Since almost every event which occurs within the system results in a message being generated, a Presentation Manager application has great freedom in the way in which it processes such events.

Message Queues

Whenever an event occurs within the system, such as the user pressing a key or selecting an item from a menu, a window being created or destroyed, or one window communicating with another, a message is generated and placed on a system message queue. Such messages are placed on the queue in the order they originated.

Each application has its own message queue, and each thread within a multi-threaded application may also possess its own message queue. This queue is explicitly created by the thread, via a function call to Presentation Manager, at the time the thread is initialized. (The term "thread" will be used herein, since message queues are always created on a per-thread basis; the application's initial message queue is created by its primary thread.)

Note that a secondary thread in a multi-threaded application need only create a message queue if it will create one or more windows. A secondary thread which does not create windows does not require a message queue.

Figure "Message Queues"

Presentation Manager periodically interrogates the system queue, removes each message and determines the window for which it is destined. It then places the message on the message queue belonging to the thread which created the window.

The thread's main routine, once initialization is complete, consists entirely of a message processing loop. The thread simply retrieves a message from the message queue via a function call to Presentation Manager, and requests Presentation Manager to pass the message to the appropriate window procedure, which is already known to Presentation Manager through the window class definition.

Presentation Manager then invokes the window procedure to process the message. When the processing is complete, the window procedure passes control back to Presentation Manager, which then returns control to the thread's main routine to obtain the next message.

If the thread's own message queue is empty when it requests the next message, Presentation Manager checks the system queue. Note that this is the only time at which the system queue is accessed; hence no other window in the system can receive a message until the currently executing window procedure returns control to Presentation Manager.

If a window procedure does not return from processing a message within a reasonable period of time, the user is effectively "locked out" of the system. In order to avoid such situations, applications which perform lengthy operations such as document formatting or remote system access, should be implemented using multiple threads, thereby allowing the application's primary thread to continue execution and return control to Presentation Manager. This technique is discussed in OS/2 Version 2.0 - Volume 4: Application Development.

Message Classes

Messages are defined and identified using message classes. A message class is simply an integer used to identify the event which caused the message.

Message classes may be of two types:

  • System-defined message classes are defined by Presentation Manager, and are used to indicate standard events such as a window being created or destroyed, sized or moved, or a key being pressed.

  • Application-defined message classes are defined by an individual application, and are used to indicate events for communication between windows in that application.

    Message classes are usually defined as integer constants. All system-defined message classes are defined in the header files which are shipped with the IBM Developer's Toolkit for OS/2 2.0. Application-defined message classes are usually defined in the application's own header files.

    The structure of a message also includes two message parameters, which are 32-bit fields passed to the window procedure along with the message. These fields may contain additional information to aid in the window procedure's processing, or may contain pointers to memory objects which in turn contain such information.

    Message Processing

    Through its window procedures, a Presentation Manager application has the ability to process messages of any type or class, in the following ways:

  • The window procedure may ignore the message, and simply leave it for Presentation Manager's own default window procedure, which will provide default processing for system-defined messages classes.

  • The window procedure may explicitly process the message, using its own logic, calling subroutines and/or passing messages to other windows as necessary. This allows processing of application-defined message classes, and application-specific, "non-standard" processing of system-defined message classes.

  • The window procedure may explicitly process the message and then pass the message on to Presentation Manager's default window procedure. This allows application-specific processing to be performed on system-defined message classes, in addition to the default processing.

    Messages may also be processed in either of two modes:

  • Synchronous processing occurs where the routine which passes the message (typically a window procedure or a subroutine invoked by a window procedure) waits until the message is passed to the target window and processed by its window procedure. Presentation Manager does not return control to the calling routine until the window procedure has completed its processing.

  • Asynchronous processing occurs where the routine which passes the message waits only until the message is placed in the thread's message queue. Presentation Manager then returns control to the calling routine.

    Presentation Manager also provides facilities which allow an application to broadcast messages to multiple windows with a single function call.

    [Back: Windows]
    [Next: Presentation Spaces and Device Contexts]