Attila Kovacs

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.

I'm chanting since ages that VCL is practically abandoned by Emba.

RDP is a kind of a double buffering, do not use double buffering with RDP

No, in berlin the same. The loop is converted to a repeat until and the debug info does not follow this transition.

Don't forget that this is not just about screen sizes. On portable devices the screen is also the input device. It's not just about wrapping some controls but usability.

wow, strange codegen, de debugger/debuginfo and the pas are out of sync

wow, I didn't know this trick: somestring > '' (Edit: I see, opcode is same as with <>) here you are decoding twice, you should optimize this, it hurts FileContent.write(TNetEncoding.Base64.DecodeStringToBytes(abase64), length(TNetEncoding.Base64.DecodeStringToBytes(abase64)) );

just got the footage per FedEx