CODEWITHSUNDEEP
delphidelphi-xe4tactionmanager
Warren P
Warren P

Reputation: 68882

Why does TCustomActionBar (and TActionMainMenuBar) clear the ColorMap property every time a CM_SYSFONTCHANGED comes in?

I am assuming that this is a bug I have to work around in TCustomActionBar that forgets about the custom colors maps each time a CM_SYSFONTCHANGED message comes in.

Looking at TCustomActionBar.CMSysFontChanged(var Message: TMessage) it calls AdjustSize, then SetColorMap(nil), then RecreateControls. There appears to be no provision in the design of the class to remember the published property ColorMap in my TActionMainMenuBar

Is there an easy workaround? IT seems I would have to be checking a lot for this condition? SHould I be hooking CM_SYSFONTCHANGED myself in a descendant class or local interposing class?

Has anyone tried this and seen if this breaks the TCustomActionBar in some other way? Is this VCL functionality essential, stupid, or a mixture of both?

My interposing class hack, which appears to work is this, is that the right way to fix it, and is there any way I can figure out where that CM_SYSFONTCHANGED message came from or any authoritative source of the various sub-meanings it might have (WPARAM and LPARAM are always zero)?

procedure TActionMainMenuBar.CMSysFontChanged2(var Message: TMessage);
begin
  { hacked version of Vcl.ActnMan }
    if not (csLoading in ComponentState) then
  begin
    AdjustSize;
    //SetColorMap(nil);  // don't want this!
    RecreateControls;
  end;
end;

Upvotes: 3

Views: 284

Answers (0)

Related Questions