WndProc(Msg) - one of the few virtual methods in TControl, it can also be used to override the main message handling procedure when inheriting a new window object from TControl;
OnMessage - a custom handler for any window messages arriving at the object window. In KOL, it is possible to assign such a handler to any window object, including an applet, form, or control, and handle any window messages sent by the system, with your code or other applications as needed. (See also AttachProc and AttachProcEx).
Many programmers, starting to work in KOL, are puzzled by the fact that the usual Delphi way of handling arbitrary messages by declaring (for example, in the declaration of a form object) a dynamic handler using the message directive does not work. So, it shouldn't work (or even compile). This directive is not supported by simple Pascal objects, but only by classes derived from TObject.
However, nothing is easier than assigning an event handler to the OnMessage event and writing code to handle the requested message. Moreover, this method allows you to expand the functionality of any window object, and not only the form (and for this there is no need to produce a new heir). On the right is an example of a hypothetical handler that processes only a few window messages while allowing others to be processed the same way. |
procedure TForm1.Form1Message (
|
The OnMessage event handler must return (Result) a boolean flag that allows further processing of this message (thus, it has the ability to prevent the message from being passed to other handlers if further processing is unnecessary or harmful). To the sender of the message (for example, to the system, if this is a normal window message), the result is returned as an integer through the Rslt parameter, please do not confuse them.
The message handling provided by the OnMessage event is not only as good as, but also more convenient than the dynamic message mechanism in the VCL. For example, such a handler can be easily added to any visual object on a form (MCK). And at the same time, there is no need to inherit your visual object class, and then come up with a way to replace the object on the form with your object (which is especially frustrating when it comes to the object used as a parent, or more precisely, the owner of the child visual objects lying on it).
Perform(msgcode, wParam, lParam) - sends a message to the object window for immediate execution;
Postmsg(msgcode, wParam, lParam) - puts a message in the queue of the object window, execution itself does not start until it is selected in the order of the queue
AttachProc(proc)- attaches the specified procedure to the list of dynamic message handlers for the window. In KOL, this is the main way to extend the functionality of existing window objects, and one of the most important tools for saving code size, since it allows you to attach a message handler required by a property only when there is a call to a certain property or when an event handler is assigned. In addition, in this way, you can attach several handlers that are called sequentially, from the last one attached to the first, until one of them returns the "do not process anymore" flag (Result = FALSE).
AttachProcEx(proc, flag) - similar to the previous one, it also allows you to specify that this handler continues to function after the moment when the application termination process has already begun (in most cases, it is required, on the contrary, to stop processing all messages from the moment when the application began to close, but there are also exceptions to of this rule);
IsProcAttached(proc) - verifies that the specified procedure is attached to the list of dynamic message handlers for the window;
DetachProc(proc) - removes the specified procedure from the list of dynamic handlers.
