Anders Melander

Thanks. I'm not using it that much myself at the moment because it takes VTune about an hour (no kidding!) to resolve the symbols of the application I'm working on 😕

Hmm. Normally I would say that maybe it could be explained by a change in the window frame width due to Win11, but given the size of the change (-317 pixels) it must be something else. Unfortunately I don't have a Win11 system with D11 on it yet so I can't try to reproduce. If you edit the DFM file in notepad and remove everything but the form properties, does the problem (i.e. open in the IDE, save file, size changes on save) still occur? If yes, can you attach the edited DFM here?

So revert to a version that does exhibit the problem and try again. You are using version control, right?

Well, save the file and compare the DFM before/after. What changed?

Well now that I think about it the setting doesn't have to be enabled. When you have a form opened in the IDE then the IDE will use the opened copy of the form (and the source) when compiling instead of using the original on disk. So let's say that loading the form somehow alters the state of the TCustomForm object. When compiling the problect this form is "saved" (i.e. the DFM is streamed in binary format) to the internal buffer and then linked into the executable as a DFM resource. If you open the form in the IDE and (view it in form designer ) and then immediately close the unit, are you prompted to save the unti?

My guess is that the values are modified on save and that you have Save on compile checked. There could be something wrong with the writers defined in TCustomForm.DefineProperties.

Need a hug? 🙂

I think even back then people were complaining that Delphi exes were too big. It's not that I can't see the beauty of small executables (I envy the size of an exe produced by a C program using only the standard libraries), the size just hasn't been a priority in what I used Delphi for for a few decades.

That doesn't really say anything. Most of Windows is written in C and asm, so are more fair comparison would be against Turbo Pascal...

Yup. Found the following comment in the Drag and Drop Component Suite source code:

No, not always. There was a time when Windows didn't handle it properly or at all. The details eludes me though so it was probably pre-Vista. You can't lay all the fault on Delphi. There have been many versions of Windows that didn't handle images in menus properly. For example I know I've had to resort to ownerdrawing menu items in Explorer context menu extensions because some combinations of menu item attributes caused the images not to be drawn or drawn incorrectly.

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.