Darian Miller

Some persistent problems with the installer and the \redist\ folder https://quality.embarcadero.com/browse/RSP-30852 https://quality.embarcadero.com/browse/RSP-33640

I'll keep your products in mind, thanks!

There recent patch links are listed here: https://github.com/ideasawakened/DelphiKB/wiki/Delphi-Master-Release-List The pages for the 10.4 patch #2 and #3 each contain a link to a how-to-install blog post from Embarcadero

VMWare Workstation Pro took out the shared VM / auto-start feature in 16.0 but added it back for 16.1 after a ton of complaints. The feature is marked as deprecated but they may be adding a new way to auto-start VMs in a future version.

And now a patch for 10.4.2 is released!

Its kinda sad that there aren't even any notes on that particular issue...which was opened in 2018. The problem is too deep into their legacy code to even attempt a fix. I don't come up against that particular issue as I wouldn't re-use the same variable name within the same routine. It's definitely a cost-benefit question on fixing it...how many people care about this particular issue, or say formatting the code or extracting a method which is likely done multiple times per coding session. But thanks, I'll add it to my list of reasons why not to use inline variables. https://github.com/radprogrammer/radteam/wiki/RADProgrammer-Style-Guide-Other-Guidance#Assume-These-Items-Are-Deprecated

I listed 4 separate QC issues (32507, 33176, 33365, 22089) and there are likely a number more. And yes, refactoring and code navigation is important. And of course, code formatting is also very important. CTRL-D needs to work so you can write code while in the groove and let it flow and then standardize/clean-up as needed during a break. I don't want to waste brain cycles on mundane tasks like fixing the spacing and alignment after editing / refactoring but I do want to try to have standardized code. CTRL-D mostly works great for my uses- but it simply cannot handle inline variables. (CTRL-D is broken for other reasons, but none that affect me as much.)

I agree that it's not doable to be fully comprehensive, but there are some major issues people should be aware of for each version. What might be useful is a list of major function topics and warnings next to each. For example, inline variables were introduced in 10.3 but should still be avoided as their usage breaks tooling. (32507, 33176, 33365, 22089) Another issue for those that rely on IDE Fix Pack would be a warning that's its not available for 10.4 but by 10.4.2 many features have been implemented. I remember being stuck at XE2, but I no longer recall what was broken in XE3 which preventing me from upgrading. We are currently in the seemingly never-ending chase of requiring to use the latest version for bug fixes, but the latest version always adds new issues. We end up with developers 'stranded' at particular versions because of major issues that they are waiting to be resolved. Eventually the perceived pain of upgrading accumulates until such time as someone decides to 'abandon ship' and switch to a different solution. This thread is an example - 10.4.2 follows with even more bug fixes than the 'quality' focused release of 10.4.1 and yet, two months after release, some people cannot use the product due to internal errors. I wonder how many developers thought that their specific pain points were finally addressed and they would upgrade to 10.4.2 and then got smacked in the face with this particular issue and finally raised the white flag (especially after waiting for months now.) For me 10.4.2 is their best release in a long while. But I'm also no longer managing complex projects with many millions of lines of code so I'm not running into this particular showstopper. However, I would really like to use inline variables, but until they fix the issues surrounding them (including the code formatter) then I refuse to use them. I assume the code formatter might be upgraded in the 10.5 release cycle and it'll take until sometime into 10.6 before it's solid so I assume inline variables are dead to me until sometime in 2023, or later. That's not intended as a slam, it's simply a reasoned forecast. Therefore it comes down to a new language feature being introduced in 2018 and forecasted to be potentially usable in 2023. Saying that out loud makes me sad and question my life choices...

That would make for an interesting resource... a list of every recent Delphi version and what major problems each of them has for users to be aware of and suggested work arounds, if available.

You can get a new Model M online: https://www.pckeyboard.com/page/product/NEW_M Classic: https://www.pckeyboard.com/page/product/UNI041A

I used the LockWindowUpdate(Handle) on BeforeMonitorDPIChanged and LockWindowUpdate(0) on AfterMonitorDPIChanged + set ParentFont := True in child controls and it helped me with this issue. (A gigantic delay was reduced to a huge delay.) I haven't checked out this repo in a while - does it help 10.4.2 at all? https://github.com/rruz/vcl-styles-utils Now that IDE Fix Pack is mostly integrated, I hope VCL Styles Utils would be another repo that was really nice to have to fill in gaps, but is no longer needed.

Interesting... how much data are we talking? Could it be posted somewhere for download?

Have you tried in-memory datasets? There's one included with Firedac. If you are manageing multiple lists of 10,000 records and indexed dataset might be worth adding to your speed test.

It looks like more acquisitions from Idera in the near future...bank account topped-up, ready to go! Apparently it doesn't affect Embarcadero much as there doesn't seem to be a lot of inter-company promotion and integration going on.

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.