Der schöne Günther

That is one of the reasons why you should, at least for closed-source development environments, always have a backup/snapshot of your full dev environment/build system that is proven to work offline (or already is offline). If one day, Embarcaderos servers don't come back again, and only then you start wondering what to do, it's already too late.

I have been doing Delphi for more than ten years now, and I didn't even know this existed. Looks like a full compilation, but without the linking. "Syntax Check" for my current project took about 30 seconds, which is less than half of what a full build takes. Thank you!

I am sure I remember something like this, back in Delphi 10.0 or even XE7. The compiler will only check the attributes if the source code file (the binary .dcu it ends up in) gets rebuilt. So if you just change something about the attributes but nothing else, it will not trigger a warning. If you do a full rebuild, it will always trigger the correct warning. I think I never bothered to file a bug report.

Did you read my post? If you don't like the Sleep(..), have the timer trigger an Event and have the thread wait for the event.

You say you need it to wake up at fixed intervals. That is exactly what Sleep(..) is for. Keep in mind that 10 milliseconds is a very, very short interval. If we are talking about Windows, then accuracy that low is not guaranteed. As far as I know, it has been improved in recent Windows versions, but generally, you cannot rely on the thread waking up again in exactly 10 milliseconds If you want the thread to wait for something else, you use an Event. You can have the thread wait for an event which is triggered from (for example) your main thread. See System.SyncObjs.pas for event classes.

In all cases? What are those cases? Can you provide a minimal example (that actually compiles) with all your test cases?

Sounds like you're trying to write an app such as this here:

No, it doesn't. What makes you think so?

Isn't that like ... the whole point of Win32/Win64? 🤔 Recommended read: Embarcadero: 64-bit Windows Data Types Compared to 32-bit Windows Data Types

One of my favourite was when an editor (obviously not RAD Studio) suggested me to rename a function slightly, so that it would become clearer that the data is processed in a specific way. Meanwhile, Delphis compiler won't even tell you when you're accidentally reading uninitialized values from records.

I made the same mistake some time back, but why don't you keep reading the existing local file as you always have? The local format settings or encodings surely have not changed? Then, save it to a new file with fixed encoding and date/time (and float!) format and finally delete the old file. At each startup, your app can first look for the "old" file format, and then the new one.

Keep in mind that while you *can* write DUnitX tests like this, you don’t *have* to. You can still just have a method and define the parameters in there. To be honest, this is what I mostly do as well. The attributes are nice when you have a test where you always expect the same behaviour, and you just want to test it with a bunch of different input values. (Can’t comment on the negative/positive testing. I mostly write tests for my very own stuff, and I’m probably horrible at it)

It's certainly not going to be trivial, but surely worth it. Been there, done that. A highly recommended read on the matter is "Working effectively with Legacy Code"

I'd say it absolutely is. You run your editor on any system, and things like inlay hints, code suggestions and compilation itself happens elsewhere. With Delphi/C++ Builder, everything is tied to running locally on a Windows computer. Or are we focusing exclusively on text editor capabilities? I might have missed that.

VS Code's frontend, for example, can run on any device (like an iPad) while the backend (compiler, linter, ...) runs elsewhere (like a computer, the raspberry in my broomcloset or in the cloud).

The string "Windows 10" or "Windows 11" does not come from the Windows API, it is a string hardcoded into the Delphi RTL (System.RTLConsts.pas). Delphi 10.2 is from 2017. Windows 11 was released 2021.

Possibly related read: Allocation-Free Collections – grijjy blog JustAddCode/AllocationFreeCollections at master · grijjy/JustAddCode (github.com)

Since about 12 hours ago, my Delphi IDE will spawn about two dozen Internet Explorer "Script Error" dialogs on every launch. I will have to dismiss every single dialog before I can continue. I can't understand why the IDE would have to use a full web browser to talk to domains I don't even know, but I'd like to disable it and get back to work. Is there a package I can disable for this "integration"? My only workaround is disabling internet access for the VM Delphi is running on, waiting for the IDE to launch and then turn it back on.

I had the same problem: How can I disable IDE talking to external websites? - Delphi IDE and APIs - Delphi-PRAXiS [en] (delphipraxis.net)

I have disabled the "Embarcadero Community" toolbar in the IDE and the issue seems to be gone now 🤞

Unfortunately, no. Even after deleting the entire WelcomePage folder from the installation directory, the problem remains exactly the same.

You will have to roll your own file picker or simply display something like "Sorry, this file is not allowed" if it's not in the correct directory. Windows regular file picker does not stop the user from entering an absolute path, following shortcuts, drag & dropping files, copying & pasting, ... the list goes on.

I have not been keeping up with the news. Are there really lots of incompatibilities on Windows on ARM left? I thought some DirectX and OpenGL stuff (games, mostly) will not work, but apart from that 99,9% of all "regular" software should?

I don't want to be a dick, but entering "CEF4Delphi" into the search box 🔍 in the upper right corner might reveal the answer

But I still don't get it - What exactly is Microsoft allegedly still waiting for? Windows on ARM has been a thing for several years now, and all major Microsoft software (I might be wrong) has been available natively for ARM for quite some time now. Granted, Apples Rosetta emulation is superior to how Windows emulates x64 code on ARM, but this is what we have now. What else would one now expect from Microsoft? From my point of view, their job is more or less done.