Application.OnMessage (
Unit Forms) oder besser TApplicationEvents.OnMessage, weil es das mehrfach geben kann und man sich nicht selbst überschreibt.
Dort kommt alles vorbei, was via
PostMessage und
PostThreadMessage im Hauptthread des Programms eintrudelt,
und durch Application.Run bzw. Application.ProcessMessages/HandleMessage durchrauscht. (die Hauptbearbeitungsstellen der MessageQueue für unsere
VCL)
Probleme gibt es nur, wenn jemand/etwas
PeekMessage/
GetMessage manuell aufruft und es nicht über Application.ProcessMessages oder .HandleMessage behandeln lässt, welche das OnMessage aufrufen.
z.B. in einigen Implementationen von Delay, als Nichthängenbleibender Ersatz des Sleep oder während ein Windows-Dialog ala
MessageBox angezeigt wird.
Diese Messages dürften via PostMessage als Broadcast im System verteilt werden
und standardmäßig nur an TopLevel-Fenster, wie z.B. die Hauptform oder das unsichtbare ControlWindow in Forms.Application.
Wie gesagt,
SendMessage kommt in dem Event blöder Weise nicht vorbei, dafür müsste man sich einen GetMessage-Hook basteln, falls es so ankommt.
https://docs.microsoft.com/en-us/win...sg/about-hooks
Es kann aber sein, dass diese Message hier nur an jene Fenster gesendet wird, welche sich vorher registriert haben.
https://docs.microsoft.com/en-us/win...enotificationa
Das Problem mit den an falscher Stelle behandelten/abgefangenen Messages, genauso wie für das übersehene SendMessage,
kann man sich da nun das WndProc seiner Form überschreiben oder die Message direkt anhängen,
Delphi-Quellcode:
procedure WndProc(var Message: TMessage); override;
bzw.
procedure WMDeviceChangeOderSo(var Message: TMessage); message WM_DEVICECHANGE; // hier geht statt TMessage auch ein passender Typ, siehe TWMSize in Forms.pas
oder man empfängt sowas in einem eigenen Thread mit einer unabhängigen "unsichtbaren" MessageOnly-Form (ähnlich der in Application).