VCL -- Understanding the Message-Handling System

Understanding the Message-Handling System

http://docwiki.embarcadero.com/RADStudio/XE7/en/Understanding_the_Message-Handling_System

All VCL classes have a built-in mechanism for handling messages, called message-handling methods or message handlers.

The basic idea of message handlers is that the class receives messages of some sort and dispatches them,

calling one of a set of specified methods depending on the message received.

If no specific method exists for a particular message, there is a default handler.

The following diagram shows the message-dispatch system:

Dispatching Messages

http://docwiki.embarcadero.com/RADStudio/XE7/en/Dispatching_Messages

When an application creates a window, it registers a window procedure with the Windows kernel.

The window procedure is the routine that handles messages for the window.

Traditionally, the window procedure contains a huge case statement with entries for each message the window has to handle.

Keep in mind that "window" in this sense means just about anything on the screen:

each window, each control, and so on.

Every time you create a new type of window,

you have to create a complete window procedure.

The VCL simplifies message dispatching in several ways:

• Each component inherits a complete message-dispatching system.
• The dispatch system has default handling.
  You define handlers only for messages you need to respond to specially.
• You can modify small parts of the message handling and rely on inherited methods for most processing.

The greatest benefit of this message dispatch system is that you can safely send any message to any component at any time.

If the component does not have a handler defined for the message, the default handling takes care of it, usually by ignoring the message.

Tracing the flow of messages

The VCL registers a method called MainWndProc as the window procedure for each type of component in an application.

MainWndProc contains an exception-handling block, passing the message structure from Windows to a virtual method called WndProc

and handling any exceptions by calling the application class's HandleException method.

MainWndProc is a nonvirtual method that contains no special handling for any particular messages.

Customizations take place in WndProc, since each component type can override the method to suit its particular needs.

WndProc methods check for any special conditions that affect their processing so they can "trap" unwanted messages.

For example, while being dragged, components ignore keyboard events,

so the WndProc method of TWinControl passes along keyboard events only if the component is not being dragged.

Ultimately, WndProc calls Dispatch, a nonvirtual method inherited from TObject,

which determines which method to call to handle the message.

Dispatch uses the Msg field of the message structure to determine how to dispatch a particular message.

If the component defines a handler for that particular message, Dispatch calls the method.

If the component does not define a handler for that message, Dispatch calls DefaultHandler.

The WndProc Method

http://docwiki.embarcadero.com/RADStudio/XE7/en/The_WndProc_Method

WndProc is the default Windows message handling function for a given control,

and the first method that receives messages on a form.

The WndProc method can be overridden in order to implement specific message responses.

WndProc passes any unhandled messages to the Dispatch method.

VCL controls have a property called WindowProc that points to the WndProc method.

This property can be used to replace or subclass the window procedure.

Before assigning a new value to WindowProc, the original value should be stored.

After completing any specialized message handling, call the original WindowProc

to make sure the normal message processing works as expected.

Note: If you are a component writer customizing the window procedure for a descendent class, y

ou should override theWndProc method instead of replacing or subclassing it.

Note: When overriding WndProc to provide specialized responses to messages,

be sure to call the inherited WndProc method at the end,

in order to dispatch any unhandled messages.

Trapping Messages

http://docwiki.embarcadero.com/RADStudio/XE7/en/Trapping_Messages

Under some circumstances, you might want your components to ignore messages.

That is, you want to keep the component from dispatching the message to its handler.

To trap a message, you override the virtual method WndProc.

For VCL components, the WndProc method screens messages

before passing them to the Dispatch method,

which in turn determines which method gets to handle the message.

By overriding WndProc, your component gets a chance to filter out messages before dispatching them.

An override of WndProc for a control derived from TWinControl looks like this:

procedure TMyControl.WndProc(var Message: TMessage);
begin
  { tests to determine whether to continue processing }
 
  inherited WndProc(Message);
end;

The TControl component defines entire ranges of mouse messages that it filters when a user is dragging and dropping controls.

Overriding WndProc helps this in two ways:

• It can filter ranges of messages instead of having to specify handlers for each one.
• It can preclude dispatching the message at all, so the handlers are never called.