Attila Kovacs

@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

doubleclick

Wish you a full recovery.

https://www.extremetech.com/computing/318020-flaw-current-measurements-x86-versus-apple-m1-performance still impressive

a right click in the editor enables it again, old bug

Who by? It's a race condition, nothing to prove. Not to mention that those implementations could change.

I had similar phenomenon after reinstalling 10.2, though only for a moment then it went away. The freshly installed component wasn't loaded. The IDE decided to treat it as a "dynamic package" and loaded/unloaded it depending on the project.

I have news regarding to IDE hang. I took the time (lot) to attach the frozen IDE to a debugger and find followings: there is a infinite message loop, affected are tlbEntityInsight NameBtn some child controls of NameBtn without any component name nor text TypeNameBtn some child controls of TypeNameBtn without any component name nor text the infinite message loop is a variation of these messages: 1328 TCM_ADJUSTRECT 46 WM_WINDOWPOSCHANGING 7c WM_STYLECHANGING 7d WM_STYLECHANGED 1328 will be triggered from: function TCustomTabControl.GetDisplayRect: TRect; Looks like this whole entity thingy is on: TAppBuilder->TEditorDockPanel->TEditWindow->TPanel Also, I have this EntityInsight turned off in the configuration. Actually I'm only using the open unit function from MMX. It happens rarely, especially on fast finger actions like formatting, saving quickly, and meanwhile the mouse is over an entity in the editor and tries to evaluate it. But then the IDE won't recover from this message loop. For the record, there is always a chance that other things are also playing a role, especially when we are debugging windows messages, so take this info as an observation, maybe it helps finding something.

@FredS Oh, thx for saying, didn't know that there was a cut. I'll go with v14 too.

Well, no pain, no gain. Used to I also stripped every RTTI because I was annoyed of the binary sizes, but once you get hooked with RTTI and its benefits, there is no back. I can remember watching those code snippets and conversations back to the days on G+ and always thought, man, for WTF do they need that, they are crazy.

Well, after more than a week without MMX (removed) I can say that not just there is no more IDE Hang's but the IDE become faster. I suspect, that even after turning off the entityinsight, it sets itself to invisible but still working in the background for some reason. On the other hand I'm missing some functions very badly.