Darian Miller

Just saw this recent blog post today from LinkedIn: https://developpeur-pascal.fr/p/_500e-les-pieges-de-l-encodage-lors-de-l-ouverture-de-fichiers-textes.html It simply goes to show that there isn't a real clean solution. I don't particular agree with this author's suggestion.

Thanks, but I'm not the right guy for that as I still want my box drawing characters above 127 for cool looking console menus. Besides, there are some references already, including: Cary Jensen: https://www.embarcadero.com/images/dm/technical-papers/delphi-unicode-migration.pdf Marco Cantu: https://www.embarcadero.com/images/dm/technical-papers/delphi-and-unicode-marco-cantu.pdf Nick Hodge: https://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf There's also a help reference: http://docwiki.embarcadero.com/RADStudio/en/Unicode_in_RAD_Studio I certainly agree that interop can be messy when dealing with third parties. Hopefully the world eventually says "Everything is now going to be UTF-8" but that will never happen. (Even if it did, there's a lot on disk that has to be converted.) I started a TextEncodingDetector unit and did think about putting it on GitHub and doing an article on it, but I'm just not the expert. A public lashing by the real experts would be a learning experience for me I suppose. If you are dealing with a stream of bytes without a BOM or external encoding reference, and need to figure out if it's UTF-8, UTF16 (LE/BE), or ANSI then it simply isn't going to be 100% foolproof and the code isn't pretty. (At least mine is not.) I think a TextEncodingDetector unit by someone like Arnaud Bouchez, François Piette, David Heffernan, Remy Lebeau, Andreas Rejbrand, etc. would be quite interesting to discuss. (Arnaud probably already has one.)

What encoding is utilized to store your data within your DB? UTF-8 is typically used on any web front end, your Delphi tooling likely prefers UTF-16, while your DB may be set to they system default ANSI code page. You need to clearly define a proper strategy to obtain data (from each different source that feeds your system), properly transfer every byte received, and then store/search the textual data in a consistent format. My assumption is that you are accepting defaults on inputs/transfers/storage and there are improper conversions going on.

While it may be an honest statement, it comes across horribly... (maybe I'm just having a bad online day with all the garbage I've seen this morning?) But at least put in the effort to document the expected behavior.

"Better late than never"

We got an August 2020 Update from the GM: https://blogs.embarcadero.com/august-2020-gm-blog/ But unlike his August 2019 update, he failed to provide any plans this time. I really thought that a new roadmap would come out along with the 10.4.1 release, but it didn't happen. I can't imagine they'll wait too much longer....get some patches out for 10.4.1 and also release the updated roadmap. It should happen before the end of the month. We did get a separate update on C++ recently: https://blogs.embarcadero.com/c-gm-update-focus-on-c-quality-in-10-4-and-10-4-1/ but no long term plans there either.

I would assume your system has been compromised.

Look for more traffic here soon as they are discontinuing their public forums. (Their current forums are horrid to use...maybe they should replace the forum software instead...) https://blogs.embarcadero.com/august-2020-gm-blog/

+1. I use a manual batch file or an automated script. Part of the batch file: echo add LiveBinding set of packages to list of globally disabled packages as they slow down form editing and am currently not using reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcomp270.bpl" /t REG_SZ /d "Embarcadero LiveBindings Components" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcompfmx270.bpl" /t REG_SZ /d "Embarcadero LiveBindings Components FireMonkey" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcompvcl270.bpl" /t REG_SZ /d "Embarcadero LiveBindings Components VCL" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcompdbx270.bpl" /t REG_SZ /d "LiveBindings Expression Components DbExpress" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcompfiredac270.bpl" /t REG_SZ /d "LiveBinding Expression Components FireDac" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Disabled Packages" /v "$(BDSBIN)\dclbindcomp270.bpl" /t REG_SZ /d "Embarcadero LiveBindings Components" /f echo Prefix description with an underscore to disable known IDE packages - added suffix signifying intentionally disabled reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Known IDE Packages" /v "$(BDS)\Bin\GuidedTour270.bpl" /t REG_SZ /d "_Embarcadero Guided Tour Package (Intentionally Disabled)" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Known IDE Packages" /v "$(BDS)\Bin\startpageide270.bpl" /t REG_SZ /d "_Start Page IDE Package (Intentionally Disabled)" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Known IDE Packages" /v "$(BDS)\Bin\TrackingSystem270.bpl" /t REG_SZ /d "_Embarcadero Tracking System Package (Intentionally Disabled)" /f pause reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Editor\Options" /v "Visible Right Margin" /t REG_SZ /d "False" /f reg add "HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0\Debugging\Embarcadero Debuggers" /v "Break On Language Exceptions" /t REG_SZ /d "0" /f

Ah, ok. I didn't try that yet.

It's a common question: https://www.ideasawakened.com/post/about-binary-compatibility-on-new-versions-of-delphi

The new drop down inserts $(Auto) Have you tried that text?

I agree and repeated it twice in my blog - always buy the source. I've been stuck with the task of replacing a component as we didn't have the source...it's horrible. The reason you buy a component is so you don't have to write that code, and you end up having to write that code or rewrite what you have in place in order to use a different component. And, your upgrade of Delphi waits until that task is done. I haven't tried that tip on a single project group for all components. I'll have to try to start doing that, thanks! A little work up front, but then saves the big hassles later.

I started a rambling reply here and it started to get long, so I put it up on my blog as it's a common question: https://www.ideasawakened.com/post/about-binary-compatibility-on-new-versions-of-delphi Note: if there any additions/corrections/clarifications needed, please let me know.

Related StackOverflow topic: https://stackoverflow.com/questions/10305634/ctrlbackspace-in-delphi-controls (Be aware of side effects.) Some history on the topic: https://devblogs.microsoft.com/oldnewthing/20071011-00/?p=24823

You could research how the Delphi IDE handles GIT commands for its integration. https://sourceforge.net/p/radstudioverins/code/HEAD/tree/branches/git-hg/gitide/

nsoftware.com has IPWorks S3, IPWorks Cloud component packages that would work. I'd suggest the full Red Carpet Subscription.

I have a TMS All-Access Subscription so I get all their cool tools. I haven't played with WebCore much yet, as there is just too much other stuff on the plate at the moment. I agree it's very forward-looking, and their VS Code target is quite impressive. Kudos to TMS for sure.

I think the team that originally took the bite had a shot, but then the R&D team was hobbled during the process of 'improved efficiencies' (aka, much more of the MRR hitting the bottom line due to much less payroll.) It was likely a business decision to quickly improve recurring income versus a lower percentage chance of Delphi taking back huge market share in the future. Developers can be an optimisitic group, money people typically aren't. On the flip side, since it likely greatly improved income, and the general desire is to keep that increased income coming in, the action probably improved the long term viability of the Windows platform support by Delphi which is where the majority of their money is derived.) The dev side of me cringed when reading that post. The money side of me said that was the risk and the lowest producer took the hit. With SWAG* math: 100 people using RAD Studio, 75% Delphi only, 15% Delphi/C++Builder Mixture, 10% C++ Builder only. 35% C++ Builder using FMX with 75% of those targeting both Android/iOS and 50% of those relying on public play stores (vs enterprise apps.) Therefore, keep the 95+ people happy at the expense of the rest. (I assume macOS could drop the 95 number by a few.) * SWAG = Scientific Wild-Ass Guess. I have no internal perspectives/sources for these numbers. Does anyone know the actual numbers?

But then again, did it run 10.3.3 OK?

I'd look at your video card ratings and ensure drivers are up to date. Perhaps the video card is underpowered.

Same here - Delphi 10.4 runs great under VMWare 15.5.5 here with no scrolling performance issues. (Just LSP and flaky form designer issues.)

There is a long list of languages to pick from and you can input code and see assembler. It currently supports a few different versions of FPC. From: https://godbolt.org/

https://community.idera.com/developer-tools/b/blog/posts/rad-studio-10-4-patch-3-is-out-vcl-grids-c-win64-debugging-and-c-android-exception-handling-and-resources

Clarifaction from David Millington out today on C++ Builder roadmap. TL;DR: Their focus is on Windows, not cross-platform right now. No Android 64-bit or macOS 64-bit support in 2020. (Discount offered to switch to Delphi.) https://community.idera.com/developer-tools/b/blog/posts/c-builder-and-platforms-support