I was going to try and report the following in the "quality" portal, but it won't let me in. (After failing on my very old password, I reset it but still go.) It's all, also, as slow as a wet week - even trying to update my screen name here timed out. Never mind, I'll post here and maybe Embarcadero will notice and/or comment.
RAD Studio 10 Seattle - update 1 - Delphi / VCL.
TWinControl.WMDestroy has the following two lines of code:
if ((sfHandleMessages) in TStyleManager.Flags) thenTStyleManager.Notification(snControlDestroyed, Self);
One result of this when using custom styles is that the style hook for the control is deleted when the window handle is being destroyed. If you have a style hook that results in a
RecreateWnd (the control is NOT being destroyed, just the handle) call then the style hook object becomes invalid in the middle of its processing and an exception may result. (For example: I have a memo that changes its scrollbar settings depending on the text.)
Another interesting point to note here is that when you change styles all window controls are recreated - but the
WMDestroy occurs
after the style has changed. So if you change from a custom style to the system style the Notification never gets called (the system style does not have sfHandleMessages set). So all the control registrations (made automatically while the custom style was active) that the above code is intended to clear out, will remain in place. ... Which leads me to the next issue.
TWinControl.Destroy has the same two lines of code quoted above. And, because of this the same problem exists: if you've changed from a custom style to the system style the old control registrations remain in place. This means that when you close the application and the
UnregisterStyleHook calls are made (either your own or those in class destructors in Vcl.StdCtrls) the processing leads to
TStyleEngine.DoUnregisterStyleHook, which includes the line:
if (LItem.Key is ControlClass) and (LItem.Value is StyleHookClass) then
Where
LItem.Key is a reference to the no longer existing control. The results are predictable: exceptions while the application closes.
I wasn't sure whether to list the above as one problem or two, since they are so closely related.
For the first problem (style hooks deleted during
RecreateWnd) my work around is to use a Detour to replace the
TWinControl.WMDestroy with a version that omits the offending lines noted above (and calls
DefaultHandler instead of
inherited - which is not available in my class helper implementation).
For the second problem I wanted to remove the "if" line and just make sure the control was always removed from style registration, but I couldn't work out how to set up a detour for a destructor, so I used the following code:
type
TStyleEnginePrivateHelper = class helper for TStyleEngineclass procedure DoFreeControlHooks;end;
class procedure TStyleEnginePrivateHelper.DoFreeControlHooks;beginTStyleEngine.FreeControlHooks;end;
procedure FreeAllControlStyleHooks;beginTStyleEngine.DoFreeControlHooks;end;
I then have my application call
FreeAllControlStyleHooks in the mainform destructor. This seems to work - because now all the
UnregisterStyleHook calls have no invalid control references left to fall over. But it's not ideal, because any dynamic (non-shutdown) calls to UnregisterStyleHook may come across have the same problems, which makes me think that maybe I should also call my special function just before changing styles.
I am left wondering if I have missed something, since this seems a significant issue that I thought would have been noticed long before now (I've only recently started playing with styles). My large project uses lots of runtime packages and lots of custom control derivations, and I'm not sure if the order of the finalization calls plays any part in the errors I was seeing. So I remain open to the idea that I am doing something wrong - but those two lines in WMDestroy don't look right to me (given that they happen after the style has changed).