Darian Miller

For what it's worth, here's a few different responses: One answer is keeping up to date with changes to Microsoft Windows... for example HighDPI support. Does your software work well with Windows 10 high dpi systems? Delphi is getting much better with this particular issue. Hopefully 10.4 finally fixes some of the issues with VCL Styles and High DPI. Another answer is compliance related - some compliance certifications require your tooling be kept up to date with all available patches/updates. If you aren't under third party audits, this is less of an issue but for security in general keeping current is wise. (Do you have the buffer overflow fix for Delphi in place?) Another answer is business risk / insurance related - It may bite you later on any future insurance claims that you knew you were out of date but didn't upgrade to fix any potential problems. Are you going to milk this thing as it is until it dies, or are you ever going to add new features? If you are going to add features, staying current may make future features easier, especially keeping up with fast changing technologies like AWS/Azure. If you are using any third party components, eventually they will drop support for older versions of Delphi. You have to assume most of the new activity in third party components surround the new releases. With more and more new language features becoming available (like inline variables) that devs really like to use which aren't backwards compatible, the rate of third party components dropping support for old versions will probably increase over the next few years. This is obviously one of the prime goals of Embarcadero - and they will keep hammering at. It's in their best interest to introduce new non-backwards compatible language features and this approach will succeed over time. Finally, the longer you wait, the harder it becomes to ever bring it back up to date. It's just delaying the cost today for higher costs tomorrow. If they are in it for the long term, they should act like it. If you are a one or two-man shop then it's certainly much harder to justify the ongoing costs due to the ever increasing price (which I assume will keep getting worse), but if you are making a decent living with the Delphi products then it only makes sense to keep them current.

I put a few more items into this repo today: - Alternative implementation from https://www.helpandmanual.com/downloads_delphi.html - Newer Hunspell en_US dictionary from SCOWL (2019.10.06) - Newer Win32 version of libhunspell.dll , built today from 2019.11.12 source, along with two small PDF docs. I have a TFrame descendant that has the spell check functionality built-in, initially built for use with TMS components. TMS has an ISpell based spell checker component that hooks into their TAdvMemo component. It's pretty easy to replace their ISpell integration with a Hunspell integration using the CCR Hunspell unit. There are a lot of recently updated dictionaries available for use with Hunspell. ASpell as another option, with a lot of current dictionaries and there's also a spell checker API in WIndows 8+ as mentioned on StackOverflow, but I haven't investigated this much..

Chris Rolliston's MPL source from Code Central is now on GitHub. You can help make it as active as you like. : ) https://github.com/darianmiller/Delphi-Hunspell

I did get a response out of Glenn Crouch @ AddictiveSoftware. Apparently still pumping out manual updates for the latest Delphi release.

I was just looking at that. Along with Rolliston's code: https://cc.embarcadero.com/item/27428 https://delphihaven.wordpress.com/2010/02/06/compiling-a-hunspell-dll-step-by-step/

What do you use for Spell Checking VCL apps on Windows made by Delphi? There seems to be two commercial options left: https://www.devexpress.com/products/vcl/spell_checker/ Included in their $1500 subscription. Don't think I want to pay $1500 for a spellchecker. https://www.tmssoftware.com/site/tmsspellcheck.asp Available alone or in their subscriptions. I'm trying to get this to work now. The old standby hasn't been updated since 2015 and forums are overrun by spam. I assume these guys are no longer around? http://www.addictivesoftware.com/

If you want to build web applications with Delphi, you'll probably want IIS.

Have you upgraded to 10.3.3? How's your crashes looking now?

Have you upgraded to 10.3.3? How's your crashes looking now?

Thanks. I didn't have that button visible: The screen is huge so it seems to be spreading all the buttons out. I simply didn't drag the project explorer window wide enough to see the Options button. Right clicking the project explorer column title area presents a popup menu with a "Text Labels" options which toggles the text labels and makes that Options button visible again. Now I can Views->Directory (Nested) to get back to normal. However, the setting doesn't save - after a restart the setting goes back to Views->List so I had to Save Desktop over the default layout to get it back to normal. So it seems a couple things happened all at once: - The Project->Views-> Directory group option was changed - The default desktop settings were saved (as this change was persistent when it normally isn't) - The Project Manager column titles were toggled to text - I got confused! : ) This setting is not in the Default Layout.dst file, but in the registry: [HKEY_CURRENT_USER\Software\Embarcadero\BDS\20.0\ProjectManager] List view: "Header0"=dword:00000107 Directory(Nested): "Header0"=dword:000001b5

Some system pause while clicking ended up with me somehow disabling the paths in project explorer under Delphi 10.3.3... do you know the magic to restore default behavior where you can collapse the file list by path? I think this happened before, but can't seem to find the solution and was hoping for a better memory than mine to help me out!

Reported: https://quality.embarcadero.com/browse/RSP-27412 Funny thing is, they found/replaced the same spelling issue in FMX.Edit.Win.pas (reported August 2015 by John Kaster on https://quality.embarcadero.com/browse/RSP-11800) But the same spelling error appears in FMX.Edit.Android.pasand FMX.Edit.iOS.pasand FMX.Edit.Style.pas

Ouch. But at least that one is protected. They can hopefully fix that one without much drama.

Delphi programmers are typically not very shy at saying how horrible something like that looks! Or opining about how bad the Quality Control is lately, or how the newer code is being created by low wage contractors instead of highly skilled craftsmen, etc... The has all the makings of those sorts of comments. And we've gone a year without it? I had to look at it 3 times from Sunday to make sure my cross eyes weren't playing a trick on me. I've done this sort of stupid thing multiple times and whenever I come across it, I typically immediately stop and fix all references. (Or if someone else did it, I tell them to immediately stop and fix it!) Call it a pet peeve I guess... I imagine if I use it, I'll put in a class helper to fix the spelling!

It's been out there for a little over a year and there hasn't been a long chain of comments yet? : ) (At least none that I found.) Maybe that just means very few are using THTTPClient...