i need to know when my application recieves a WM_SETTINGCHANGE
message (formerly known as WM_WININICHANGE
).
Problem is that the message pump in TApplication sends it down a black hole (default handler) before i can get a chance to see it:
procedure TApplication.WndProc(var Message: TMessage);
...
begin
Message.Result := 0;
for I := 0 to FWindowHooks.Count - 1 do
if TWindowHook(FWindowHooks[I]^)(Message) then Exit;
CheckIniChange(Message);
with Message do
case Msg of
WM_SETTINGCHANGE:
begin
Mouse.SettingChanged(wParam);
Default; <----------------------*poof* down the sink hole
end;
...
end;
...
end;
The procedure CheckIniChange()
doesn't throw any event i can handle, neither does Mouse.SettingChanged()
.
And once the code path reaches Default
, it is sent down the DefWindowProc
drain hole, never to be seen again (since the first thing the WndProc does is set the Message.Result
to zero.
i was hoping to assign a handler to a TApplicationEvents.OnMessage event:
procedure TdmGlobal.ApplicationEvents1Message(var Msg: tagMSG; var Handled: Boolean);
begin
case Msg.message of
WM_SETTINGCHANGE:
begin
// Code
end;
end;
end;
But the OnMessage event is only thrown for messages that come through the message pump. Since the WM_SETTINGCHANGE
message is "handled", it never sees the
PeekMessage
TranslateMessage
DispatchMessage
system.
How can i respond to the windows broadcast WM_SETTINGCHANGE
?
Edit2: For older versions the usual message intercept should work...
Edit: Ooops! Did not see it was for D5. The following was in D2007+.
Use an OnSettingChange in your Application:
You can test with this code. Try and change the height or docking side of the TaskBar...
The answer was in my question, the dangerous, undocumented, use of
HookMainWindow
:You handle it just like you would any other message. TApplication's default handler will route it correctly if you set up a message handler for it: