Der schöne Günther

To be honest, I don't think any of this is new - It's been like this for several years now. I've just come to accept it. Over the last years, the IDE has gotten better, but just cannot compete with others , it's in a league of its own. For example, Visual Studio 2017 got its last bugfix in August 2023. Now imagine Delphi 10.2 still getting fixes...

Can't you just step into System.InitUnits() or put a breakpoint there?

I can only say that we have shipped a four-digit number of systems with Windows Professional during the last years which have to run constantly 24/7. With "Automatic Updates" set to "Disabled", they might still be using Windows Update to update Windows Defender signatures, but they surely do not install major OS updates that require a reboot.

If it's Windows Professional, then you can just disable automatic updates through local group policies (run gpedit.msc). It works absolutely fine, it's just that there is no GUI for setting this with the regular windows control panel anymore.

HKEY_USERS contains a bunch of "S-IDs" which stands for the user accounts on your machine. HKEY_CURRENT_USER is nothing more than a shortcut/alias to HKEY_USERS\[your S-ID]. This probably means that you are running Delphi not as the current user you used to open "regedit" with, but as another user.

Good catch, that would have taken me hours as well. For the sake of completion, here is the official documentation on the matter: Threading model for WebView2 apps - Microsoft Edge Development | Microsoft Learn

Not true at all. This was the case around 10 years ago with Windows RT. Yes, there is software that might not run out of the box (like apps based on OpenGL or DirectX), but for "regular users", most software runs without users even realizing it is being emulated.

Can confirm with Delphi Alexandria 11.1: The program is executed correctly, but the stepping through it with F8 inside the debugger jumps around: It goes like this: Begin SetLength End of method Back to for loop End of method back to the foor loop end of method done I suppose it's some weird kind of compiler optimization or the debugger just setting the breakpoints in the wrong places.

I learned that the IDE will also get confused when you have two or more projects in a group (call them "A" and "B") and when you have a frame "TMyFrame" in both project "A" and "B". It will sometimes show A.MyFrame in project B and vice-versa, depending on which frame was opened first.

I don't have at hand how you had to set up the TFDConnection (and possibly the Sqlite bridge) with the FireDAC components, but here's a starting point: How To Corrupt An SQLite Database File from Sqlite.org itself. Also, see https://docwiki.embarcadero.com/RADStudio/en/Using_SQLite_with_FireDAC, it's surprisingly helpful:

If you have no trouble identifying every item by filename alone, I'd personally go with the raw filesystem. Reason is that you can easily purge older files, add or remove content without going through your application which eventually have to be updated. Not sure about the type of app you're building, but sticking with raw files has often helped me so that a technician on site was easily able to "remove all garbage data from scanner 2 between 13:00 and 13:15" without me adding something like this to the application or editing a big database file. Also you can easily corrupt your sqlite database file with sudden power losses and stuff like this. If you set it up correctly then it doesn't happen, but I think the default settings of FireDAC have the journalling behaviour set up so that it is not robust against power losses. It's a mistake I have unfortunately made more than once. I think NTFS (or at least, Windows Explorer) starts having trouble after around 10.000 files in the same directory. You should definitely have some subfolders that also allow you to group/sort things easier. Like a folder for every new day or something like this.

Yes, I have read that comment, but I am not much wiser. I have honestly never bothered with this, and now I wonder if I should have. The core of the motivation is "Refactor the code, so the compiler trips over its own feet less"? What is "DCU cache stability" Marco mentions? Is it that Delphi often does not register source files updating (for example, by switching version control branches) and then tries to link outdated DCU files in?

Can you elaborate on the motivation? Why should one care about unit interdependency? To speed up compilation?

Thank you, that clarifies it. I don't think this is intended behaviour and probably a bug.

Well, have you tried just having an empty implementation of TMainForm.FormSaveState(..)? I have not tried, but I would assume that when OnSaveSave gets called, you app has already been sent to the background and is about to be suspended within the next few milliseconds. Instead of actually saving something, your code example is now stuck on waiting for a confirmation for a non-visible dialogue. I would assume that the operating system either discards your handler or maybe entirely termiates your app because it appears stuck.

That does not sound like intended behaviour. Does that also happen if your implementation of the OnSaveState event is completely empty?

Change your CommandLine:= 'c:\windows\system32\cmd.exe /c ping -t 127.0.0.1'; to CommandLine:= 'ping -t 127.0.0.1'; and your ping.exe will properly be terminated. Right now, you are killing cmd.exe which, in turn launched another ping.exe. Of course ping.exe will still be around after cmd.exe got killed. Also, TerminateProcess(..) should always be a matter of last resort. Properly terminating the ping -t command is, as you've found out, sending a [ctrl] + [c] event. You can do that from your own app: GenerateConsoleCtrlEvent function - Windows Console | Microsoft Learn

Do you have control over Exe-2 or is it by somebody else? If it is, can you be sure that the behaviour of Exe-2 might be changing in the future?

iOS betas hardly change dramatically over the time. By the way, final release is in like 8 weeks. Having a development tool that is now unable to produce working executables, that is worrying, and not wasted time.

Just saying: Your source is just a copy from @Remy Lebeau's original post on https://stackoverflow.com/a/37949303

That's Microsoft, just casually leaving OutputDebugStr-calls in their release builds. Nothing new here 😑 If you don't use the debug output, you can disable these messages showing up in the IDE. If you do, you will have to get used to your messages being buried under a heap of garbabe.

of course, I still haven't created the promised follow-up ticket 😓

I made it so that it works both with and without the T as it's more readable without it. [Test] [TestCase('Date, space, time', '1988-10-21 17:44:23.456')] [TestCase('Date, T, time', '1988-10-21T17:44:23.456')] [TestCase('Date, T, time, Z', '1988-10-21T17:44:23.456Z')] [TestCase('Date, T, time, offset (1)', '1988-10-21T17:44:23.456+02:30')] [TestCase('Date, T, time, offset (2)', '1988-10-21T17:44:23.456+0230')] procedure TestDateTimeArgument(dateTime: TDateTime); https://github.com/VSoftTechnologies/DUnitX/blob/c348ea5010822368975c0f10aa1d16969c6ba6bd/Tests/DUnitX.Tests.Example.pas#L68-L74

At least more than three🙄. Judging by the readme file, it is newer than September 2016, but as you noticed, older than June 2020 when my change was added.

I contributed ISO8601-compliant DateTime parsing to DUnitX: VSoftTechnologies/DUnitX: Delphi Unit Test Framework (github.com) I'd recommend using ISO8601 so that it doesn't depend on the build machine's locale.