Leaderboard

This is an rather old thread but I'd like to give my 2c for future readers: I was lead of a team modernizing a huge (300+ forms, 3+ MLOC) Delphi application. The major part of the modernization process was about styling it, using VCL Styles. We used Delphi 10.3 at that time, and then eventually we migrated to Delphi 10.4. It took 3 months and we decided to purchase a 3rd party library (StyleControls) to make the process easier and faster. StyleControls has simliar controls (e.g. buttons) that work better with styles than the standard ones. Besides that, SyleControls have some classes to help styling controls that don't support VCL Styles directly (e.g. the DevExpress grid that we extensively use in our application). Disclosure: I'm not connected to StyleControls company in any way. Regarding VCL code, some hacking was necessary to fix bugs that couldn't be avoided and no workaround was found (mostly runtime patching of VCL classes). We also used the Rodrigo Ruz's VCL Style Utils package, and it also required some tweaking (nothing major though). Repainting of complex forms when resizing can also be problematic. A non-styled VCL form with hundreds of controls will repaint itself very fast and there is very little flicker. The same form when styled will cause a severe and ugly flicker that can't be ignored and we also needed to find ways to reduce or interrupt form refreshing in many scenarios in order to reduce this effect. But basically I disagree with who says that it doesn't look professional, or "not quite there yet". The final result looks nice and professional, although there are things that could be improved and refined. The application has been in production, with thousands of users and the general feedback has always been positive. I think it's totaly worth it.

Nah nah nah nah, can't hear you. I just added support for Alpha AXP to my application with SetPEFlags(IMAGE_FILE_MACHINE_ALPHA). Neat huh?

Yes: Install v23.2.3 There is no "workaround". To support Delphi 12 with an older version you would have to replicate the things they've done in 23.2 and then you might as well just install 23.2

Hi, Sherlock, I disagree with you. I don't think styles are a toy or a waste of EMB time and money. Styles are a necessary tool to allow us developers to modify our apps. I agree that massive changes are ill-advised and will confuse the user. But many modern apps (including the IDE) have a dark mode, which is what we are using styles for. We're not going to make massive changes to the UI that would confuse the user.

That's what I thought. What about the part that pointed out the futility of setting the flag without having the corresponding compiler support?

Indeed, a bit sad. I still have hope that this will get some traction shortly. It might be worth to know that a fork of that repo, namely https://github.com/UweRaabe/Delphi-Unit-Tests, is actually part of the regression tests run by Embarcadero. It also has a couple of contributors as well as branches, albeit lacking some activity, too.

I am going to try to see if I can make the changes to the application. I will wait just a bit longer to get you the link so that you can get the DBNavigator version if I am successful in implementing the changes.

When I look at that .ini file, there is a Unicode character U+202F (Narrow No-Break Space) in between "11:15:12" and "AM". I think TryStrToDateTime() only supports the ASCII space character U+0020, so likely can't handle that other type of space character and so fails the parse.

The problem with that approach is that you may not get a decoding error, so you wouldn't really know which encoding "works" right away. You might just end up with garbage when reading data. And what do you consider to be "valid"? Because different formats can produce results without errors, but just won't be what you are expecting. Can you parse the string first to make an educated guess about its likely format before you then try to decode it as a TDateTime? Yes, and more than that, its the BOM for UTF-16LE specifically. So you can use TEncoding.Unicode when loading the file. Actually, internally TMemIniFile reads the file into a TStringList first before parsing it, and TStringList is smart enough to look for a BOM when no TEncoding is specified, so in theory TMemIniFile should be able to load your file in the correct encoding provided a BOM is always present and TMemIniFile.Encoding is nil. However... The file you have provided has a UTF-8 BOM, not a UTF-16 BOM. So your example code would need to use TEncoding.UTF8 instead of TEncoding.Unicode (or, don't specify the encoding at all and let TMemIniFile figure it out for you).

I've now added the code and demo (with documentation!) for what I have been using as a replacement, here.

I develop only VCL for Windows and my target are almost exclusively Win10 e Win11 (and Win2012 server+). Windows 7 practically disappeared from my customer PCs and Windows 8 never appeared. In my scenario I'm happily using styles: with latest Alexandria 11.x EMB provide at least 4 default VCL styles HIDPI compliant 2 for Win10 and 2 for Win11 (2 = light + dark). I decide in real time the style to use based on the SysOp and the user's choice to use the light or dark theme of Windows and I get an acceptable result and an UI compliant with that of the SysOp. Without styles in VCL its impossibile to create dark apps.

Any style that differs from the current OSes UI style and style guide, will cause an application to look and feel strangely out of place. You might want or like that, but most of the time users will feel uneasy about it as soon as the initial "wow how pretty" effect has faded to "why is the quit button green?". So in essence styles to me are just another toy where Embarcadero has wasted precious time and money, both of which are direly needed in other areas of the product.

Is it unreasonable to expect that programmers have knowledge and skill?