Leaderboard

To avoid flooding another thread with unrelated posts about VCL quality and bugs, I have opened this topic for discussion about VCL in general and VCL Styles. First, I would like to respond to comment made by @Attila Kovacs VCL is not abandoned, not even close. Maybe it is not receiving too many new features as people would hope so, but it has more to do with its maturity than anything else. FMX (is) was in frenzy development cycle, only because it didn't have the needed features VCL already had, and it still does not have all. So it may have seemed that FMX is getting all the love and attention, but that was not the case. Many new Windows related features introduced since FMX has come to play, are still VCL only. Keep in mind that IDE is based on VCL, and I don't see that changing in foreseeable future. VCL is evolving and it will continue to evolve. It is not that FMX is new better, improved framework mean to replace VCL for all purposes, it is framework with completely different architecture and it covers different use cases. While some functionality certainly overlaps, and there are (Windows only) applications where both VCL and FMX can be chosen, there are also applications where VCL is far better (and sometimes, even only viable) choice. VCL Styles are buggy, they have been buggy since they were introduced in XE2. But, they are now part of the IDE. That means two things. First, IDE is now suffering from some bugs, but it also means that those bugs will get fixed sooner rather than later. Unfortunately, not all bugs can be solved overnight, and the more specific, reproducible bug reports there are, the higher are chances that those bugs will get a fix. If you have any filed VCL bug reports you might want to share, please do so.

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

Although Vcl.Styles is not mature. I would say it is usable. The Delphi IDE is a proof of that. I have been producing PyScripter with Vcl.Styles for the last five years, and I had no issues that could not be overcome. And now you can have per monitor aware, styled Delphi applications. And since this this discussion started about flicker, there are ways of working around that. The Delphi IDE and PyScripter have minimal flicker. The great thing about Vcl is that applications developed almost 20 years ago, can still work well and look modern, just by recompiling pretty much the same old code. I have mentioned this before, just compare to the Microsoft Desktop application landscape. A new framework is introduced every 3-4 years, mostly incompatible with the others: - Visual Basic with ActiveX controls - C++ with Windows API - WinForms - WPF - Silverlight - Xamarin - UWP - WinUI - MAUI - Project Reunion - etc. Where would you be if you invested in Visual Basic and ActiveX controls for example? Ironically, you can still use ActiveX controls in Delphi if you so wish.

"Let's put dots into unit names, add some confusing matching logic for uses clauses that nobody understands and call that namespaces"

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.

Detail noticed: Order is initially ok, IF the default style is not Windows (but for example Iceberg Classico) and only becomes problematic after switching to another VCL Style (other than Windows). // order with default VCL style <> Windows, immediately after startup TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TListView TTreeView // order after switching to VCL style <> Windows TListView TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TScrollingStyleHook.TScrollWindow TTreeView ( The order we always get with the workaround is the same as the initial order without workaround. )

Yet another evidence: It's sufficient simply to reorder children in Z-order for bug to disappear. And Z-order is the order in which EnumChildWindows function reports child windows. And so, it's most probably the order in which DestroyWindow function processes child windows. function MoveScrollWindows(hwnd: HWND; lParam: LPARAM): BOOL; stdcall; var c: TWinControl; begin c := FindControl(hwnd); if c is TScrollingStyleHook.TScrollWindow then SetWindowPos(hwnd, HWND_TOP, 0, 0, 0, 0, SWP_NOMOVE + SWP_NOSIZE); Result := True; end; procedure TMainForm.FormClose(Sender: TObject; var Action: TCloseAction); begin EnumChildWindows(ClientPanel.Handle, @MoveScrollWindows, 0); end;

@David Schwartz This was the calculator company (Mathatronics) I was part of it, as a head engineer as a young engineer, to develop a chip calculator. https://www.oldcalculatormuseum.com/a-math3.html The machine you see in the picture was wired with transistors and my function was to change it to a chip. I was using all the companies at a time to develop the chip for us. We installed the calculator in a building! for the people to use with the little box you can also see in the picture. P.S this is what it knew to do https://www.oldcalculatormuseum.com/a-mathpkb.html All with wired transistors

Good observation. And its quite strange that your workaround affects the issue, because: In the demo you can switch between VCL Styles any times and, then, switch back to Windows style. Obviously, in this case CM_STYLECHANGED will be processed one or more times, but no bug will occurred an the end. CM_STYLECHANGED does not received after form's close button click. So, there should be some resulting side effect - a difference in the application's state with and without workaround. So, I've decided again to look at the child windows of the panel. The code: var s: string; function EnumProc(hwnd: HWND; lParam: LPARAM): BOOL; stdcall var c: TWinControl; begin c := FindControl(hwnd); if c = nil then s := s + 'nil' else s := s + c.ClassName; s := s + #13#10; Result := True; end; procedure TMainForm.Button1Click(Sender: TObject); begin s := ''; EnumChildWindows(ClientPanel.Handle, @EnumProc, 0); ShowMessage(s); end; With the system style: With VCL style: And with the workaround from @pyscripter: So, with workaround, we have at least different child windows order.

Scoped Unit Names issues pretty much made me decide to make XE2 the minimum version I will support in my open source projects. Even then, I still have issues every day so I typically run a build in every version to at least see if it compiles.. it's so easy to break things for different compiler versions without realising! The next update to DUnitX and Delphi-Mocks will drop < XE2 support. TBH, I think we are doing the community a disservice by supporting very old (pre XE2) versions of delphi in libraries.. if we want delphi to continue we need people to upgrade occasionally!

I'm refactoring usage of various different look-up tables and I'm trying to come with 1 fast look-up table design. Most of them have 1 thing in common: search by integer (ID) and search by string (Name). All data is sorted. So, I bench-marked TArray.BinarySearch, TDictionary and custom binary search. Even though a flaw in design was pointed out for TArray.BinarySearch, (see https://en.delphipraxis.net/topic/4575-why-is-tarraybinarysearch-slower-than-normal-binary-search-function/), I still wanted to compare results: For search by integer, custom binary search seems to be a little faster than TDictionary, until large tables: For search by string, custom binary search wins even more, still for not large tables: Interesting is that for smaller searches, 10 records, a sequential search is faster than TDictionary. I also tried TGpStringHash (by Primoz Gabrielcic), which is very fast, but unfortunately no implementation for integers. TSynDictionary (from mORMot) is also very fast, but I don't use mORMotand license is not friendly for my commercial project. Is there any other fast search implementations that is not too specialized and ready to use out of the box, that I can try?

"I:\GExperts\Projects\DelphiXx104Sydney\GExpertsRS104.dproj" (rebuild target) (1) -> (_PasCoreCompile target) -> I:\GExperts\Source\UsesExpert\GX_UsesExpert.pas(374): error F2613: Unit 'GX_StringGridDrawFix' not found. [I:\GExpert s\Projects\DelphiXx104Sydney\GExpertsRS104.dproj] 0 Warning(s) 1 Error(s) The unit is there, I added it to the project and was able to build. This build seems to have fixed the assertion error I was seeing during shutdown 😉

I see this in TScrollingStyleHook.TScrollWindow.CreateParams: Params.Style := Params.Style or WS_CHILDWINDOW ...

There are two separate things here. VCL and VCL Styles. You said that VCL is being abandoned by Embarcadero and that is simply not true as there is a huge difference between "not receiving too many features" and being abandoned. Also by "not receiving too many features" I definitely didn't want to say it barely received any. There were numerous features introduced in VCL since XE2, some were VCL only, some were both VCL and FMX. The part with bugs and IDE and "overnight fixing" is strictly related to VCL Styles. Only introducing styles to IDE exposed how buggy they really are and how much fixing they need. And that amount of fixes cannot be made overnight. VCL is mature framework. I never said that for VCL Styles. VCL Styles were never mature, they are just feature that was never properly finished in the first place. I hope this is more clear now.

Hi All Small progress update on DPM - https://github.com/DelphiPackageManager/DPM - some tweaks to make it possible to use DPM with projects that use runtime packages. v0.1.54-alpha Release https://github.com/DelphiPackageManager/DPM/releases/tag/v0.1.54-alpha Package compilation will now build version info if the package dproj has it enabled. There doesn't appear to be a way to pass that info into msbuild, so I plan to look at updating the dproj file with the correct version info before compilation. Implemented Copy Local feature for runtime packages. For projects that use runtime packages, dpm packages that produce runtime packages will be copied to the output folder. Copy Local is still a little rough around the edges... it doesn't detect if the project actually references the bpl's - that's more difficult than it sounds due to differences between dcp and bpl filenames (libsufffix comes in play here). So for now, you may end up with extra bpl files in your output folder if you use runtime packages. Fixed project group support on install command. Improved handling of relative project file paths. Cleaned up logging. Added batch file for downloading dev dependencies (only needed for developing DPM).

We were thinking of writing a blog post about it, I'll ping the person who was looking at doing so. For more detail I'll need to ask our engineers. My level of oversight here was to ask we fix RD bugs, I did not dig into the details of what changes we made or why.

If memory taken by whole strings is not a problem, I would use whole strings. (Or lossless compression of this string.) Do you include parameters into this hash? Because SELECT a.Value FROM Table a WHERE (a.Id=:Id) can produce different results for different parameters.

I opened new thread for more general discussion about VCL and VCL Styles

@David MillingtonThe features of Parnassus Debugger are great, but I am getting assertion errors with the Parnassus Debugger and Delphi 10.4.2. I am also getting Index out of bounds errors. These occurred while debugging simple Vcl apps (nothing fancy) and they don't occur in the absence of the Parnassus Debugger. Is https://quality.embarcadero.com/ the right place to report issues related to the Parnassus Debugger.

The issue results from the TListView being recreated as a response to the CM_STYLECHANGED message (see CustomListView.WndProc). If you add the following at the top of UMainForm.pas TListView = class(Vcl.ComCtrls.TListView) protected procedure WndProc(var Message: TMessage); override; end; with the following implementation procedure TListView.WndProc(var Message: TMessage); begin if (Message.Msg = CM_STYLECHANGED) then begin if ViewStyle = vsReport then UpdateColumns; end else inherited; end; the error does not happen. There does not appear to be much point in recreating the ListView, since its handle would have already been recreated, when the form it resides gets recreated. Still it remains a mystery why the recreation of the ListView affects the TreeView! The memory leak is also prevented by calling RecreateWnd after changing the style. In the process of debugging, I discovered another Vcl bug: [RSP-33221] CM_STYLEDCHANGE is broadcast twice - Embarcadero Technologies

I started to use Pascal in the beginning of '80. I don't remember the exact year but it was something like 1981. At that time I used Pascal on a Motorola 68000 development system to build an image processing system for the industry. I also used USCD Pascal but I don't remember the exact context. Later I moved to C on microcomputers and then CP/M machines and the IBM-PC. On the PC, I used Pascal MT+ at lot before using exclusively C for long time, actually until Delphi was born. And much later, in 1995, I moved to Delphi that I still use today, every days.

If you want it to always run elevated, you can specify that in the manifest.