TActionMainMenuBar and TActionToolbar lose settings

I stumbled across a really weird behavior recently. When I use a TActionMainMenuBar (or a TActionToolBar) in my program, compile and run, and then start Photoshop CS5 or Internet Explorer 9, the ActionMainMenuBar (and ActionToolBar) loses all its settings. The colors defined in the assigned colormap disappear and the font settings are also lost. Has anyone seen this before and knows a workaround?

D2007 Pro (all updates applied), D2010 Pro (all updates applied), Vista Home Premium 32 bit, NVidia GForce 8600 GT, latest driver installed.

Steps to reproduce:

1. Drop a TActionManager and a TActionMainMenuBar on a form
2. Create a category with some menu items
3. Drag category onto ActionMainMenuBar
4. Assign TwilightColorMap to the ActionMainMenuBar
5. Run program
6. Start IE9 or Photoshop CS5
7. Watch all predefined settings disappear (you have to close IE9 again to see the effect)

If you start Photoshop or IE first and then the Delphi program, nothing happens. The bug is also present when in design mode in the IDE. A fellow developer has already confirmed the described behavior for his system with Win7 Pro 32bit and a ATI Radeon 9800 Pro.

Thx for any comments/ solutions

Phil

PS: Using Photoshop CS3 doesn't produce this bug

Here's one other way of reproducing the problem:

• Complete steps 1 to 4 as in the question (including dropping a TwilightColorMap).
• Add a button to the form with the code  Perform(WM_SETTINGCHANGE, 0, 0); in its click handler.
• Run the application and press the button.

So now we know that a WM_SETTINGCHANGE broadcast might be causing the problem, we might wonder if launching IE produces the same:

type
  TForm1 = class(TForm)
    ..
  protected
    procedure WMSettingChange(var Message: TWMSettingChange);
      message WM_SETTINGCHANGE;
    ..

procedure TForm1.WMSettingChange(var Message: TWMSettingChange);
begin
  Memo1.Lines.Add(IntToHex(Message.Flag, 4) + ', ' + Message.Section);
  inherited;
end;

After we run our application and then launch IE, a few seconds later the below appears in the memo:

0000, Software\Microsoft\Internet Explorer\SearchScopes

I have no idea what IE has to say to our form (and all other top-level windows) at every launch, and I don't know if it is doing this on every Windows box on earth or just yours and mine, but evidently the ActionMainMenuBaris no good at handling it.

A win control (the form), receiving a WM_WININICHANGE, performs a CM_WININICHANGE and upon receiving it broadcasts the same to all its controls. The below is how it is handled by the menu bar:

procedure TCustomActionMainMenuBar.CMWininichange(var Message: TWMWinIniChange);
begin
  inherited;
  RequestAlign;
  Font.Assign(Screen.MenuFont);
end;

Thinking that the system menu font could have been changed (the code should have looked for a 'WindowsThemeElement' or 'WindowMetrics' section in the message, but anyway..), it is reassigned from the refreshed Screen.MenuFont. The problem is, we weren't exactly using it.

Additionally the ColorMap responds to a CM_WININICHANGE by resetting its colors by calling its UpdateColors method. This is even documented:

UpdateColors is called automatically when an ActionBand component receives a CM_WININICHANGE message.

---

So the solution would involve deciding what to do and overriding both behavior, I tried to comment the below solution for why I believe that it would be the correct solution:

type
  // Derive your own ColorMap that would reset its own colors.
  // This is an interposer for simplicity..
  TTwilightColorMap = class(actncolormaps.TTwilightColorMap)
  public
    procedure UpdateColors; override;
  published
    property Color default clGreen;
    property FontColor default clYellow;
    property MenuColor default $4488FF;
    // reintroduce as many property as necessary, probably all is necessary..
  end;

  TForm1 = class(TForm)
    ..
  private
    FSaveMenuFont: TFont; // will hold initial main menu bar's font settings
  protected
    procedure WMSettingChange(var Message: TWMSettingChange);
      message WM_SETTINGCHANGE;
  end;

..

procedure TForm1.FormCreate(Sender: TObject);
begin
  FSaveMenuFont := TFont.Create;
  FSaveMenuFont.Assign(ActionMainMenuBar1.Font);
end;

procedure TForm1.FormDestroy(Sender: TObject);
begin
  FSaveMenuFont.Destroy;
end;

procedure TForm1.WMSettingChange(var Message: TWMSettingChange);
begin
  inherited;
  // The below are the *section*s that really changing system settings
  // would notify that I'm aware of, there may be more...
  if (Message.Section <> 'WindowsThemeElement')
      or (Message.Section <> 'WindowMetrics') then
    ActionMainMenuBar1.Font.Assign(FSaveMenuFont)
  else
    // Develop your logic here. The system menu font might really have been
    // changed. You can get it from Screen.MenuFont. But then if we had been
    // using the system font, the control already applies the change by default.

end;

procedure TTwilightColorMap.UpdateColors;
begin
  inherited;
  // Reset your colors, note that system colors might have been
  // changed or not. If changed, they should be reflected in 'cl..' constants.
  Color := clGreen;
  FontColor := clYellow;
  MenuColor := $4488FF;
end;