- Introduction
- Message Handling: Not "Contract Free"
- Assigning Message Result Values
- The TApplication Type's OnMessage Event
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Message Handling: Not "Contract Free"
Unlike responding to Delphi events, handling Windows messages is not "contract free." Often, when you decide to handle a message yourself, Windows expects you to perform some action when processing the message. Most of the time, VCL has much of this basic message processing built in—all you have to do is call inherited to get to it. Think of it this way: You write a message handler so that your application will do the things you expect, and you call inherited so that your application will do the additional things Windows expects.
To demonstrate the inherited elements, consider the program in Listing 1 without calling inherited in the WMPaint() method. The procedure would look like this:
procedure TForm1.WMPaint(var Msg: TWMPaint); begin MessageBeep(0); end;
This procedure never gives Windows a chance to perform basic handling of the WM_PAINT message and the form will never paint itself. In fact, you might end up with several WM_PAINT messages stacking up in the message queue, causing the beep to continue until the queue is cleared.
In some circumstances, you don't want to call the inherited message handler. An example is handling the WM_SYSCOMMAND messages to prevent a window from being minimized or maximized.