After reading this question, I tried to let the end user change my application's style at runtime. This has lead to a very long list of memory leaks with content like this:
A memory block has been leaked. The size is: 12
This block was allocated by thread 0x130C, and the stack trace (return addresses) at
the time was: 404B3E [frxDsgnIntf.pas][System][@GetMem$qqri][1993] 454B77
[System.SysUtils][Sysutils.WideStrAlloc$qqrui] 454BB2 [System.SysUtils]
Sysutils.StrNew$qqrpxb] 53046E [Vcl.Controls][Controls.TWinControl.DestroyWnd$qqrv]
57E1C7 [Vcl.ComCtrls][Comctrls.TCustomTreeView.DestroyWnd$qqrv] A53DEE [JvComCtrls]
TJvTreeView.DestroyWnd$qqrv] 530733 [Vcl.Controls]
Controls.TWinControl.DestroyHandle$qqrv] 530703 [Vcl.Controls]
Controls.TWinControl.DestroyHandle$qqrv] 530703 [Vcl.Controls]
Controls.TWinControl.DestroyHandle$qqrv] 7552FEB6 [EnumThreadWindows] 530703
[Vcl.Controls][Controls.TWinControl.DestroyHandle$qqrv]
The block is currently used for an object of class: Unknown
Almost all of the leaks are in frxDsgnIntf.pas, except for all the components on the form which lets the user to change the style and all point to this procedure:
with TdlgSettings.Create(nil) do // leak here according to FastMM report
  try
    if ShowModal = mrOk then;
  finally
    Release;
  end;
Does anyone know if I'm doing something wrong or this is the expected behavior of TStyleManager when changing styles? Here's the code which changes the style at runtime:
procedure TdlgSettings.cbThemeChange(Sender: TObject);
begin
  TStyleManager.TrySetStyle(cbTheme.Text); // cbTheme.Items lists all the themes which are included the application
end;