Attila Kovacs

Is it tested now? Btw. interestingly WM_NCDESTROY's are still coming for all of the windows. The chained list theory fails? also as switching the freeing order of the scrollbars (vertical,horizontal to horizontal,vertical) free's the horizontal fine, then vertical becomes the next in the z-order and freeing it breaks the message chain again. If it has actually something to do with the Z-Order. Edit: Just to make sure, I've compiled the testapp with D2007 and D5, and run it even on XP, it's always the same.

I can't test it as ForceQueue is not present in Berlin, but in theory looks good.

Destroying a window from a different thread? Does it work?

this is really below every standard but what about if not (csDestroying in Application.ComponentState) then it works fine and I can't see any just as simple solution

I'm currently here

Buhh. Well, this is a new problem. Still, there is no legitimate reason to call consecutive DestroyWindows.

Aha! Now I'm getting closer. Have to fire up a new form to check.

in class destructor TStyleEngine.Destroy; FreeAndNil(FControls); will free all remaining StyleHooks. Who cares by who or when will it be free'd on closing the application?

The above non-quality? "fix" resolves the problem calling nested DestroyWindow and thus stopping WM_DESTROY propagation. The application does not yield any new leaks so I don't understand your point, what am I missing?

Ok, i see what you are saying, the remove should be evt. called, free() not. But the dictionary will be free'd even if it's not empty. So, I guess doesn't matter. Edit: no, calling remove results in other leaks. It was just fine that way.

Exactly this is the problem. That is what I wanted to avoid. Those are parented to the parent of the ListView and will be destroyed by the window manager.

stylehooks are no windowed controls like the scrollbar

just copy the vcl sources to your project dir and alter them it works evt. could be further higher in the callstack

if not (csDestroying in Control.ComponentState) then begin FControls.Items[Control].Free; FControls.Remove(Control); end; in class procedure TStyleEngine.DoRemoveControl(Control: TWinControl); cut nested calls to DestroyWindow

Looks like on RecreateWnd it's necessary to free the two themed scrollbars, but at the moment the window manager kicks in with destroying all controls, it becomes a problem. I've tested on W7, it's the same. I like the workaround to eliminate the message broadcasting like @pyscripter suggested as this seems to have more advantage. Otherwise, creating a transparent container between TListView and its Parent could eventually solve the issue. I'd say give it as-is to Emba, let's see how they think about it, maybe they have more comments in the VCL.

@balabuev Nice work! I replaced the buttons with TListViews with some Nodes and the leak appears. Do we know where the dog is buried or is it time to ask Mr. Chen? Looks like it's only happening if we are destroying the next window in the order, then it's stops all the propagation of WM_DESTROY's, like if there were an exception in the window manager. If we skip one control it's fine again (4 buttons, freeing Nr. 3 on Tag1, not Nr.2).

@emailx45 does not work with code or am I dumb

@emailx45 I don't know how does it work. Was it introduced to the community?

If I stop broadcasting the CM_STYLECHANGED it looks similar at the end as with HWND_TOPMOST. I'm just wondering what regression that pulls with it. The double destroy on the same handle appearing here too.

can we test it on other than W10? it's very strange

@balabuev The themed scollbar is just a parented window, not a child. Or am I wrong on that?

Exactly that's why we wish VCL would be threaten a bit better. We don't need fancy calendar components every year, just a solid base where the developer doesn't have to invest hundreds of hours to track down bugs, creating workarounds and hoping the fix proposal will be taken over. For example, if you have theming, and one single bug makes it look dumb, you don't have anything. If you have HDPI support, but then you have to patch it for yourself and keep syncing the changes with the new releases, you won't be happy. If you have Raise, you are very angry right now. God bless the 3rd party developers for making professional components and making possible to live the RAD feeling.

It's the scrollbars, in TScrollingStyleHook.InitScrollBars changing SetWindowPos(FVertScrollWnd.Handle, HWND_TOP, Control.Left + Left, Control.Top + Top, Right - Left, Bottom - Top, SWP_NOREDRAW); to SetWindowPos(FVertScrollWnd.Handle, HWND_TOPMOST, Control.Left + Left, Control.Top + Top, Right - Left, Bottom - Top, SWP_NOREDRAW); (both, vertical and horizontal) also solves the problem without reordering the windows nor blocking the VCL to recreate the wnd's with stopping the CM_STYLECHANGED broadcast. However the re-broadcasting is still results in multiple recreatewnd's which is slowing the theme-change down massively, the solution is not as easy as just stopping re-broadcasting. Yes, the question remains still the same. Are the handles screwed up on the nested recreatewnd's or are there any Z-Order logic in Windows' internal wndproc or are those WM_DESTROY messages with invalid handles which are arriving was one of the lost TListView.

So you just gave the things an indian name "not receiving too many new features as people would hope so", and telling us that its evolving but only things getting fixed which are part of the IDE, and mentioning "overnight" fixes and "mature" but buggy since XE2. That was a rollercoaster to read.

Not just with styles but it's the cream on the cake.