Windows Messaging
Windows Messaging
Understanding how Windows works at a low level can make the high-level programming process a lot easier. Just as
important, it can help developers to get the results they expect from their programs and to avoid many of those
unpleasant surprises.
Windows is a message passing system. Every event, from clock ticks to mouse moves and from key presses to mouse clicks,
generates a message. Each of these messages has a specific window as its destination address; each message communicates
data such as the mouse location, which mouse button a user clicked, what key was typed, whether the key was released, and
so forth.
Messages include unique identifiers, and there are hundreds of important system messages, most of which start with a "WM_"
prefix. Clicking the left mouse button, for example, generates a WM_LBUTTON message, while the right mouse button
generates a WM_RBUTTON message. In addition, separate messages would be generated when a button is pressed (DOWN),
released (UP) or double-clicked (DBLCLK).
Using Visual Basic terminology, each message passes parameters "by reference" and not "by value". In other words, a
message passes a pointer to the parameter's memory address, rather than passing specific parameter values. The
coordinates of the mouse cursor might be set into a data structure, for example, and then the address of that data
structure is passed as a Windows message parameter. Developers often use the stack, which is itself a last-on/next-off
structure, as the mechanism for passing these parameters.
In addition, the data to which a message points can be changed by other programs before a message reaches its final
destination. That final destination window will never know the message had been intercepted and its parameters modified.
This process is known as "sub-classing," and many useful Windows utilities perform these kinds of tasks.
Finally, the destination window operates upon the message and its contents in an endless succession until the system is
turned off. Resizing a window, data entry, drag-and-drop and all the other aspects of a windowing system are served
through this process, all of which is overseen by the executive -- Windows itself. By default, the operating system
typically directs all non-system messages to the highlighted window of the current application.
Spying on Messages With WndProc
When a message reaches its destination, it is usually directed to a routine known as "WndProc." If a message is targeted
at a particular WndProc routine, the associated application then operates upon the message (remember, this is the only
real means by which communications takes place on a Windows system). Each WndProc on a system is called one at a time;
the message is operated upon and then passed on to the next WndProc routine. This continues until the WndProc list is
exhausted, and then the process continues with the next message.
As a result of this process, slow or poorly written applications can adversely affect the entire system. An application
can, by "swallowing" or modifying messages in the Wndproc chain, do odd things--some humorous, others intrusive or buggy.
Although there exist an enormous number of pre-defined message types (these message types can be found in the "winuser.h"
file), nothing prevents a new one from being defined and operated upon in some new and exciting way by an application,
either.
Controls As Windows
As you drag Visual Studio controls from the various toolboxes onto a form, you're actually seeing only a visual
representation of the control; the actual programming and functionality of the control are behind the scenes, safely
ensconced behind the Visual Studio GUI. Each VS control is actually a fully functional window, responding as required to
messages, such as WM_PAINT (to redraw itself) or positioning messages when dragged across the active form. Each control's
window includes a set of intrinsic properties, including its relative position, foreground and background coloration,
size and so forth.
Windows itself is just responding to the messages you (and your programs) generate.
gfx.sikander
--
www.sanyam.tk
"the future's in the air, Can feel it everywhere !!"
Understanding how Windows works at a low level can make the high-level programming process a lot easier. Just as
important, it can help developers to get the results they expect from their programs and to avoid many of those
unpleasant surprises.
Windows is a message passing system. Every event, from clock ticks to mouse moves and from key presses to mouse clicks,
generates a message. Each of these messages has a specific window as its destination address; each message communicates
data such as the mouse location, which mouse button a user clicked, what key was typed, whether the key was released, and
so forth.
Messages include unique identifiers, and there are hundreds of important system messages, most of which start with a "WM_"
prefix. Clicking the left mouse button, for example, generates a WM_LBUTTON message, while the right mouse button
generates a WM_RBUTTON message. In addition, separate messages would be generated when a button is pressed (DOWN),
released (UP) or double-clicked (DBLCLK).
Using Visual Basic terminology, each message passes parameters "by reference" and not "by value". In other words, a
message passes a pointer to the parameter's memory address, rather than passing specific parameter values. The
coordinates of the mouse cursor might be set into a data structure, for example, and then the address of that data
structure is passed as a Windows message parameter. Developers often use the stack, which is itself a last-on/next-off
structure, as the mechanism for passing these parameters.
In addition, the data to which a message points can be changed by other programs before a message reaches its final
destination. That final destination window will never know the message had been intercepted and its parameters modified.
This process is known as "sub-classing," and many useful Windows utilities perform these kinds of tasks.
Finally, the destination window operates upon the message and its contents in an endless succession until the system is
turned off. Resizing a window, data entry, drag-and-drop and all the other aspects of a windowing system are served
through this process, all of which is overseen by the executive -- Windows itself. By default, the operating system
typically directs all non-system messages to the highlighted window of the current application.
Spying on Messages With WndProc
When a message reaches its destination, it is usually directed to a routine known as "WndProc." If a message is targeted
at a particular WndProc routine, the associated application then operates upon the message (remember, this is the only
real means by which communications takes place on a Windows system). Each WndProc on a system is called one at a time;
the message is operated upon and then passed on to the next WndProc routine. This continues until the WndProc list is
exhausted, and then the process continues with the next message.
As a result of this process, slow or poorly written applications can adversely affect the entire system. An application
can, by "swallowing" or modifying messages in the Wndproc chain, do odd things--some humorous, others intrusive or buggy.
Although there exist an enormous number of pre-defined message types (these message types can be found in the "winuser.h"
file), nothing prevents a new one from being defined and operated upon in some new and exciting way by an application,
either.
Controls As Windows
As you drag Visual Studio controls from the various toolboxes onto a form, you're actually seeing only a visual
representation of the control; the actual programming and functionality of the control are behind the scenes, safely
ensconced behind the Visual Studio GUI. Each VS control is actually a fully functional window, responding as required to
messages, such as WM_PAINT (to redraw itself) or positioning messages when dragged across the active form. Each control's
window includes a set of intrinsic properties, including its relative position, foreground and background coloration,
size and so forth.
Windows itself is just responding to the messages you (and your programs) generate.
gfx.sikander
--
www.sanyam.tk
"the future's in the air, Can feel it everywhere !!"
0 Comments:
Post a Comment
<< Home