Anders Melander

Comparing the map files could provide a clue.

Reminds me of this one:

Well I got curious and peaked at the source anyway. It seems you can call AbortJob on the query even while it's blocked. Also, TFDConnection.AbortJob just iterates the connected datasets and calls AbortJob on each of them.

I don't have time right now to check the FireDAC source but it seems strange if FD has been designed so you can only cancel a non-blocking query. The natural pattern would be to execute a blocking query in a thread and cancel that from another thread (e.g. the main thread). Anyway, it seems you can cancel the query at the connection level via TFDConnection.AbortJob.

16 colors ought to be enough for anybody? 🙂

Out of memory errors in threaded applications can be really hard to recover safely from. It largely depends on allocation pattern and the nature of the out of memory error. In single threaded applications it's easier but there's still no guarantee that it can be done safely. The problem is that once you run out of memory you might not have enough memory to report and handle the problem. Luckily an out of memory error is often caused by to trying to allocate a big hunk of memory and if that allocation fails then there's still memory available, just not enough to satisfy that particular allocation request. One "trick" that I've used occasionally is to allocate a large recovery block when the application starts. If an out of memory occurs then this block is deallocated, the allocation is retried and the user is notified that they're about to run out of memory. You will need a custom memory manager (or just a wrapper around the existing one) in order for this to work and multi threading might get in the way. Or you could just recompile for 64-bit 🙂 With regard to not being able to handle the error in the async execution; Couldn't you just execute the query in your own thread instead and handle the problem there?

If you plan on doing this with a mobile phone then just turn the chair around and record the person against the live background... It's called a selfie I hear 🙂

You don't have to tell them that the problem still exists. They know that they haven't fixed it. You won't get any meaningful answer to your question.

https://quality.embarcadero.com/browse/RSP-22089?jql=text ~ "formatter inline"

TL;DR Your discontent IMO has nothing to do with the topic and only sabotages the OPs attempt at a discussion.

I can't say that I disagree wrt the localization tools. I only wish they would have admitted that they were completely broken (apparently beyond repair) 20 years ago, and deprecated it then, so we didn't have to waste time on that dead end. That said, while the ITE/ETM tools never worked, the RTL part of the localization system (i.e. resourcestrings, resource modules, etc) has always worked very well IMO. With regard to gettext/PO-files I've never had much success with it because it basically just translates phrases without regard for context. There are functions in gettext to translate with context, but the context has to be specified explicitly in code. https://www.gnu.org/software/gettext/manual/html_node/Contexts.html

Instead of hijacking this thread with yet another off-topic wall of text about why Embarcadero sucks and Delphi is doomed, maybe you could start your own thread?

I would leave the bundled Indy, and the global library search path, be and instead add the Indy repo as a submodule to the project repo and add the local path to that submodule to the project search path. Of course that only works as long as the design time properties of the bundled Indy and the one in the Git repo are compatible.

I'm afraid the integrated localization tools has been officially deprecated. Unfortunately the documentation still hasn't been updated to reflect this fact. https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Release_Notes#Translation_Tools So your best option is to use one of the many alternatives available. There exist both commercial and freeware solutions. I'm the author of one of the freeware solutions (the one linked to by Darian above) so I'll leave it to others to list the pros and cons of the different alternatives.

And even without them we're now stuck with the zero based string helpers. What a turd.

I'm sorry about that, although I don't quite understand why you find it offensive. I'm sure Joe knows his stuff but appearance does matter. I actually looked at the site trying to find more information about the library but eventually gave up. Now that I look at it again I can see that what I thought was just more bullet points is actually links to sub pages. After that I had to read through all the FAQ to deduce that it's not a native Delphi library. If I had actually been looking to buy a PDF library (I'm not since I have a DevExpress subscription) I would have taken one look at that page and quickly moved on. Joe or not.

Marketing strategy? Really? Just because you disagree with the decision to deprecate it doesn't make it a stupid decision, driven by "marketing". The deprecation of "object" was also controversial but that wasn't driven by marketing either. I'm pretty sure management, marketing and sales couldn't care less about these things.

I hope Joe is better at coding than designing web sites 🙂

I too miss Rudy, but to be honest he was also the main reason I stopped participating in the old fora; So many interesting topics deteriorated into endless yes, no, yes, no, discussions. That and the misuse of moderation power that were going on killed my interest.

Sure, except you simply have another version of Windows to support, which is typically another VM to keep around. It would be nice to delete the old Windows VM and simply use the latest version of Windows to support all of your projects, including the ancient ones.

Or even one 😱 ( 🙂 )

You are probably right on that, but do the software running on those systems really need to be supported by Delphi 11? I doubt it.

Yes, they probably realized that there's no reason to resort to hacks when there's better solution

Support for older versions of Windows doesn't come for free. Official support means that they need to test against those versions and that they can't use the APIs of newer versions. Given the minimal market share of XP it hardly seems worth using resources to support it. If support for XP is required then use a version of Delphi that supports XP instead. I myself am on Windows 7 and if (when) that breaks Delphi then I will only blame myself.

It's relevant when you're wondering why they can't get it working properly. I'm not sure but I seem to remember that the formatter was written in J# or some horror like it. Technical debt indeed. Their solution to that appears to be letting those old features rot until everyone has given up on them and then remove them from the product. On that account, the formatter and refactoring features days are numbered. Fair enough; We all have to work within the limits of available resources. So let someone else work on those tools that they can't maintain themselves. What's to lose? Anyway, I known very little about LSP but if it can supply a good detailed DOM then I guess one could write a better formatter on top of that with relative ease. A few years back I looked at writing a formatter, using some of the available Delphi parsers, but none of their DOMs were detailed enough for the purpose.