Since I had captures messages inside the main message loop, I forgot it is straightforward: create a [WayBack] TApplicationEvents instance, then use the [WayBack] OnMessage event and hook it to a method like
procedure TMainForm.ApplicationEventsMessage(var Msg: TMsg; var Handled: Boolean); begin // figure out if the TMsg should be handled; set Handled to True if you do not want it to be processed by your application any further // if you do not handle it: bail out as quickly as possible // for performance reasons, it might be wise to have only the decision in this method, and all actual handling (including any managed variables) inside another method. end;
Capturing these messages is limited to the ones processed through the main message loop (or message pump): these are the asynchronous ones either put there by PostMessage or related functions (like PostQuitMessage), or generated by Windows.
This means you will not see any synchronous messages sent to specific Windows using SendMessage.
Unlike the documentation for the OnMessage event, the type inside the method is TMsg from the unit [WayBack]WinApi.Windows, which is an alias for the (documentation mentioned) tagMSG in the same unit; neither type is documented at docs.embarcadero.com or docwiki.embarcadero.com. Luckily, it is documented in the Windows SDK as the structure [WayBack] tagMSG.
That structure is not the same as the [WayBack] TMessage type inside the unit WinApi.Messages [WayBack], as TMessage omits these fields from TMsg:
HWND hwnd;DWORD time;POINT pt;DWORD lPrivate;
Luckily the [WayBack] TMessageEvent (that describes the type of the signature of the event method) is better in this regard:
TMessageEvent = procedure (var Msg: TMsg; var Handled: Boolean) of object;
TMessageEventincludes the following parameters:
Msgidentifies the Windows message that triggered the event.Handledindicates whether the event handler responded to the message. If the event handler setsHandledtoTrue, the application assumes that the message has been completely handled and halts any subsequent processing of the message.
TApplicationEvents is actually a multi-cast component (one of the very few multi-casting things parts of the Delphi VCL): an undocumented TMultiCaster class inside the unit Vcl.AppEvnts [WayBack].
A bit reminder though: ALL queued (not sent!) Windows messages flow through this method, so make it as short and efficient as possible, so from the OnMessage documentation:
OnMessageonly receives messages that are posted to the message queue, not those sent directly with the Windows APISendMessagefunction.…
Warning: Caution:Thousands of messages per second flow though this event. Be careful when coding the handler, because it can affect the performance of the entire application.Tip: Call theCancelDispatchmethod from anOnMessageevent handler to prevent the application from forwarding the event to any other application events objects.
TCustomApplicationEvents.CancelDispatch to be documented:Prevents other TCustomApplicationEvents objects from receiving the current event.
A few more relevant links if you want to also hook SendMessage based messages:
The Wiert Corner - irregular stream of stuff 