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;