Broad Network


Message Basics for Window Class Procedure

Getting to know Windows – Part 4

Volume - Windows User Interface

Forward: In this part of the series we look at message basics for the window class procedure.

By: Chrysanthus Date Published: 28 Aug 2012

Introduction

This is part 4 of my series, Getting to know Windows. I assume that you have read all the previous tutorials before this one. You should be reading the tutorials in the order given. In this part of the series we look at message basics for the window class procedure.

Note: If you cannot see the code or if you think anything is missing (broken link, image absent), just contact me at forchatrans@yahoo.com. That is, contact me for the slightest problem you have about what you are reading.

Event
An event is an action that depends on time. A window operates by waiting for an event to occur. The event will cause a message to be sent to the window class procedure (through a queue). The class procedure will process the message. Very basic messages that are common to all windows, should be sent to the default procedure by the class procedure.

Window Messages
Input reaches the window procedure as messages. The message can come from the operating system or from the application or from input devices. The system generates a message at each input event, such as when the user types on the keyboard, moves the mouse, or clicks a control such as a scroll bar. When a user resizes a window, that is an application message.

Recall: the prototype for the window class procedure is:

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam);

The message reaches the window procedure as a set of four parameters: a window handle (hwnd), a message identifier (uMsg), and two values called message parameters (wParam and lParam). We saw this in the previous part of the series. The window handle identifies the window for which the message is intended. So even though one procedure can be for many windows, the message does not go to all the windows; it goes to the one identified by the handle.

A message identifier is a named constant that identifies the purpose of the message. It can be something like, WM_PAINT, which is an identifier (variable) that identifies a particular integer. When a window class procedure receives a message, it uses the message identifier to determine how to process the message. For example, the message identifier WM_PAINT tells the window procedure that the window's client area has changed and must be repainted.

The two message parameters specify data or the location of data used by a window class procedure, when processing a message. The meaning and value of the message parameters depend on the message identifier (uMsg). A message parameter is also an integer (different integers have different meanings). When a message does not use message parameters, the parameters are typically set to NULL. A window procedure has to check the message identifier to determine how to interpret the message parameters.

Another way to look at this is, that the message identifier has the message and the parameters have the message data (or data location).

Queued Messages
Everything being equal, all messages are lined up in a queue. The message that came first into the queue is sent out first. The message that came second is sent out second; third message that came is sent out third; and so on. This is a first-in-first-out queue. Remember, a message consists of the window handle, the message identifier and the two message parameters. More than one window can be opened at the same time. The window handle identifies the window that will receive the message processed by the window class procedure.

When the user moves the mouse, clicks the mouse buttons, or types on the keyboard, the device driver for the mouse or keyboard converts the input into messages and places them in the system message queue. The operating system removes the messages, one by one, from the system message queue and sends them to the class window procedure. We shall see more about this later.

Nonqueued Messages
Messages that are not queued, deal with emergency messages. An example event is when a user clicks a window to activate it so that it should be ready to receive keyboard input. This is an emergency. In this case, the operating system sends a series of messages to the window class procedure directly, bypassing the system message queue.

If you are my fan, then you know that most of my series begin with coding. So, I know you are very eager to start coding. You still need some patience; but do not worry; you will start seeing code in the next part of the series.

Let us take a break here and continue in the next part.

Chrys

Related Courses

C++ Course
Relational Database and Sybase
Windows User Interface
Computer Programmer – A Jack of all Trade – Poem
NEXT

Comments

Become the Writer's Fan
Send the Writer a Message