Leaderboard

Part 2: The demo with simple three buttons on a panel. RunTestClick destroys the panel handle using DestroyWindow function. Button1 is the first in Z-order, and thats why it will first receive WM_DESTROY message. In the message handler it will destroy Button2 recursively. And the test shows, that in this case Button3 will not receive WM_DESTROY. ButtonsTest.zip

As @David Millington mentioned, we have been working with the R&D team to share tips learned to help speed up VCL applications under remote desktop - to read about it, including a code sample see: https://blogs.embarcadero.com/how-to-speed-up-remote-desktop-applications/

The above image is what my Grep results window looked like after compiling version 1.3.17 and using it for a while in Delphi 10.4.1. After reading and trying suggestions in the discussion about the Grep window being blank and nothing working, I went into the GExpert's registry entries and discovered the value "ContextHeightPercent" was set to 125. Reducing the value under 100 fixed the problem. My guess is after checking the check box "Save context display (fixed) height", something caused the Context section to get set above 100% and from then on nothing would allow me to set it lower. I did not look at the code, but I would think it needs some logic to keep the context section from going over some value less than 100% to keep it from covering over all the other components.

I'm currently here

https://pastebin.com/YCiqiNAq Pretty simple but effective. Hasn't failed me yet.

Good subject BTW - I learned GetSystemMetrics(SM_REMOTESESSION) and redesigned DoubleBuffered usage in my apps that are running on remote PC's

This is not true. StyleEngine.Destroys calls FreeControlHooks which destroys all remaining hooks. However what @Attila Kovacs suggests is problematic, since you keep accumulating unreleased hooks if the application creates and destroys styled controls.

stylehooks are no windowed controls like the scrollbar

OTOH I wouldn't be happy with something like Microsoft.Interfaces.Winapi.IOUtils.TPath.PathDelimiter

I can imagine a linked list iteration inside DestroyWindow function, like: cur := FirstChild; while cur <> nil do begin nxt := cur.Next; ProcessNode(cur); cur := nxt; end; If ProcessNode will (as in our case) recursively delete the next node from the list - the function will fail, because it already fetched the pointer to the next node into its local variable. However, if ProcessNode will delete the next next node (the node after next) - nothing bad will happen. I think it's not necessary. For example, when scrollbars are hidden these controls may stay untouched. On the other hand this may be the simplest fix.

I think the original subject line for this thread is one where this is quite understandable (and not a bad thing). There is a role for a forum where "rambling discussions" are accommodated. If you look at many other threads here they are more "particular problem focused". Mind you I am completely with everyone here, agreeing that Embarcadero made a disasterous decision when they chose to close down their forum. If you are looking at a new development system in this modern age one of the first things to check is how active is the community on the forum..... As I've said before as well as losing community visibility and the huge volume of useful technical knowledge they also closed down a valuable source of customer feedback. So "Kind of ridiculous... very sad.".

Since Delphi do not support multiple class inheritance, you should use interfaces. A class can support many interfaces. So TSalesManager can support IHuman, ISales and IManager interfaces. At the class level, you can delegate an interface implementation to another class.

@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).

I'm not going to talk about delphi 10.4.2 because I still have 10.4.1. But on sdk, you don't need to use this Embarcadero tool, it is almost always a version behind. Ideally, you should install Android Studio on your own, open it and Configure> SDK Manager and install (download) the latest sdk, get the directory and configure it in your Delphi Options > Deployment > SDK Manager> Android

I've solved this puzzle In short - this is not about handles recreation, this is about handles destruction. And the order of destruction plays essential role here. First, I want to recall again, that the process starts in form's destructor, which calls DestroyWindow function. And as specified in MSDN, DestroyWindow will actually destory all children window handles recursively, and each of destorying window should receive WM_DESTROY message. It vital to understand that the destruction of a handle does not imply the destruction of the corresponding control. Control can exist without its handle. Opposite is not possible - each control destroys its own handle during the control destruction. So, from this viewpoint, form destruction is a two stage process: A single call to DestroyWindow in a form destructor deallocates all handles of all child controls on the form. And only after that, child controls are destroyed recursively. So, what is happening in the demo. Given the following panel child order: List view is the first child control of the panel, which will receive the WM_DESTROY message due to form's DestroyWindow call. List view's TWinControl.WMDestroy message handler will eventually call the following: TStyleManager.Notification(snControlDestroyed, Self); The above notification will force the style hook to destroy two owned TScrollWindow controls, which at this time have its handles allocated, and so, each of the TScrollWindow control, will call DestroyWindow recursively. So, this recursive calls of the DestroyWindow (where the nested function call destroys the window, which was already enqueued for destruction in outer function call) is the cause of the bug. This may be either: illegal usage of DestroyWindow function by Delphi or Windows bug. I don't know. Part two is comming, in which I'll reproduce this strange behavior with a simple three buttons placed on a panel (no relation to VCL Styles at all).

a "timesharing calculator"! LOL!

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.

I'm once again in need of a good 64-bit profiler so I've been looking into what would be needed in order to generate PDB files from whatever Delphi can produce. First of all it seems the only good debug info source on the Delphi side is the MAP file and the format of that seems a bit unstable. However since it's a text file it should be easy to adapt to any changes in it. Then there's the PDB file format. The only good and reliable documentation of that appears to be what the LLVM project has produced. Microsoft at one time published some of their source code for dealing with PDB files but since then the repository appears to have gone into limbo and they have not kept it up to date like they said they would. Anyway, in short, a PDB file is a MSF container file consisting of a number of streams containing the different debug info in CodeView format. The MSF format is pretty simple and since I only need to produce PDBs I don't need to bother about decoding MSF files. That leaves the PDB CodeView streams. Thanks to the LLVM documentation their format are known. However, after reading the LLVM source, it has become clear that it would be a huge task to implement all the different stream formats and all the different data types. I guess one could get by with a subset but it doesn't really seems worth the effort to create something that only works sometimes. The biggest problem however is that I would be implementing something based on a port of a third party's interpretation of Microsoft's old (and by now out of date) source. PDB is an internal VS format and Microsoft has stated that it can, and mostly will, change with each new version of VS. For this reason they provide the Debug Interface Access API for those that need to read PDB files. Unfortunately there's no (known) corresponding API to write PDB files. PDB support is important for the LLVM project (they too would like VTune to work with their output ) so they appear to be trying to keep up with the PDB changes and since they obviously have more resources for that task than I do I've decided to aim for a solution that piggybacks on their work instead of rolling my own. The solution I'm going to try is to parse the MAP file in Delphi, write out the relevant information in YAML format and then use the LLVM llvm-pdbtil tool to convert the YAML to PDB. Sounds easy and it probably would be except for the fact that the required YAML format is undocumented... The llvm-pdbutil yaml2pdb documentation does a handwave with "The YAML syntax is not described here. Instead, use llvm-pdbutil pdb2yaml and examine the output for an example starting point.". Lazy bastards Anyway, this was just a dump of the information I've been able to gather on the topic of generating PDB from Delphi in case I burn out before completing anything usable.

C++Builder 10.4.2 improves this a lot. It's not perfect, but much improved. Please try it out.

This whole saga is typical of the VCL Styles support - in short, it's a mess. My guess is they really don't have anyone inhouse that is an expert with this stuff, so various people (contractors?) tinker with individual issues without an overall picture of things and with an impact analysis. You only have to look at how double buffering is handled 15 different ways in the vcl for various controls. Then there's the overpainting that happens when controls are resized (the whole form is repainted for each control). https://quality.embarcadero.com/browse/RSP-30639 And the response to it has been laughable at best. They "fixed" the design issue by tinkering with one affected control (TMemo) but left the rest (citing the need for interface changes) - but now they expect us to enter separate issues for each affected control! I suspect that is so they can split the tasks up to different people... so we can get more of the same tinkering. Seriously, if you are not already using VCL Styles, then don't bother with it.

Thank you very much for all the help, the mentoring was done by @vfbb in a very satisfactory way, and here is my recommendation.

Um... no. To be "nicer", all the replacement code would have to be better than the existing Delphi code. At least much of the current Delphi code is stable. Rewrite your biggest project in a hurry and see if it's better.

Double buffering is absolutely one of the things that you don't do when over RDP. Because then you give up app the benefit of transmitting the logical drawing instructions and instead have to send raster images. But I wouldn't say RDP is double buffering. You don't draw to off screen bitmap and the flip it or blit it. If you want to draw text, you send the text and instructions of where to draw it, and then the actual rendering happens at the other side. But yeah, advice to double buffer is wrong. Correct advice is the opposite. Don't ever double buffer in a remote session. More on that here: https://devblogs.microsoft.com/oldnewthing/20060103-12/?p=32793 This may come as a shock to a lot of Delphi devs for whom the standard reaction to flicker seems to be to enabled DoubleBuffered on the form/control.

CreateWindowHandle/CreateWnd are VCL Wincontrol routines that can be overwritten to take action that needs to happen when the WindowHandle of a control gets (re)created. There are corresponding routines DestroyWindowHandle/DestroyWnd, but these routines are only called when the control is recreated and not when it is destroyed. It appears that this is known, see for example here and here. I came across this issue because I wanted to do the following when a contol's handle was created: RegisterDragDrop (Handle, DropTarget); and this has to be matched by: RevokeDragDrop(Handle); at handle destruction. Initially I placed the first statement in an overwritten CreateWindowHandle and the second in DestroyWindowHandle. This resulted in memory leaks and I began to investigate. Here are the results of the investigation that I wanted to share with you in case you face the same issue. 1. DestroyWnd is only called when recreating the control (not at control destruction). It also calls DestroyWindowHandle. This is documented in the help file. 2, DestroyWindowHandle is called by DestroyWnd and separately by TWinControl.Destroy if WindowHandle <>0. So it looks like my solution should work, however, when the control is a child of a TCustomForm and the form gets destroyed (almost always the case), TCustomForm.Destroy calls DestroyWindowHandle before destroying child objects and Windows, before destroying a control's handle, it first destroys the window handles of all child objects. So the DestroyWindowHandle of the child controls will not be called! WindowHandle = 0 inside TWinControl.Destroy. The choices you have for taking action before handle destruction are: 3. WM_DESTROY handler. It is called by windows before destroying the window handle of child controls. 4 WM_NCDESTROY handler. It is called by windows after destroying the window handle of child controls and before destroying the control's window handle. I ended up putting RevokeDragDrop inside the WM_DESTROY handler, since this is called in all cases the window handle gets destroyed. Although not a bug, this looks like bad VCL design to me and can be the source of many bugs.

Devastating.. just look at this "thread". Completely unorganized after just a few replies. Like a text message thread, but worse. And wondering when this site is to be retired? Next week, a year?? There is no guarantee at all on a site like this, as I can see it. Kind of ridiculous.. very sad.