Brandon Staggs

Yup, which is just one more reason why safety through automatic initialization is illusory.

Much easier said than done if you have a large legacy application built around Trident. If you are using a lot of synchronous javascript calls the refactoring job to work in the asynchronous Edge browser is no small refactoring task. Obviously it would be a worthwhile thing to do, IMO, but of course that needs to be balance against other concerns...

FMX project with MacOS target. Anyone else doing this, have you found a satisfactory way to get reports of runtime exceptions? On Windows we can choose from madExcept or EurekaLog, and I cannot find anything like that for FMX projects on MacOS. When running via PAServer one can at least read exceptions in the logging output, but more often than not, carefully placed Asserts for debug builds in the hands of testers (no PAServer) which are very helpful in Windows are useless on Mac, just killing threads or silently blowing up with a disappearing window...

Funny, that was the first step in the right direction I've seen Bezos take with the Washington Compost.

I'm seeing this more and more lately. It is very worrisome that people actually think these autocomplete engines are authoritative and will actually argue with you if you present facts that disagree with the text generated by these tools. They may have their uses, but this is borderline scary.

The fact is that any design-time component can crash the IDE. All you have to do is uninstall them all and see if your problem persists. If it does, you can be relatively certain it is the IDE itself and not a component. You seem very resistant to this basic troubleshooting step. That doesn't seem rational. I agree that Delphi quality is not where it needs to be. I do not agree that the IDE is as useless and impossible to use as you have said. Shrug.

To be clear, I do compile MacOS (Arm64) targets. It seems self-evident to me that the comparison you suggest is invalid. Doesn't make a difference either way; unless Windows on ARM is a passing fad, which I doubt, we need a compiler that can target it.

I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet. Ostensibly, the benefit will be not having to rely on a layer of processor architecture emulation. I certainly can't see the benefit of Embarcadero pretending there is no ARM64 Windows executable format and ignoring it altogether. If you decide the x64 output works better you aren't going to be forced to distribute ARM64 binaries.

This also depends on application. There is no way I would trade my desktop AMD cpu for Snapdragon. I do not care about power consumption there and there is no comparison on performance. But on a laptop, I am already using Snapdragon and I am pleased with it. I don't know what we're arguing about here. Personally I want the ability to target Arm64 on Windows now that there are seriously good Windows computers using the architecture.

I wouldn't know. I don't build for Linux and I don't work for Embarcadero.

The x64 compiler is no paragon of code output. I think it would be nice to not have to rely on Embarcadero writing its own compilers. Obviously it goes without saying I would hope they configure the toolchain properly for good output, too. Performance and power use. So far the testing of Windows applications on Snapdragon indicates you're going to get the best performance and efficiency with native code, which is exactly what one would expect...

The events of the last six months have certainly changed some of my opinions on this, but I am still trepidatious about an LLVM ARM64 Windows compiler "just working" with code that has been in production for 25 years. And regardless of my concerns about potential issues, I very much want an ARM64 Windows compiler as soon as possible. I'd actually like the option to build x64 with LLVM as well. Whatever issues there are to deal with, such as making sure exception handling works as I expect it to, I'll deal with them.

You may not understand how Delphi works. In Delphi, all of your third-party components are DLLs running in the IDE's process. That's how RAD works, for better or worse, and it means that problems in third-party components will often cause havoc in your IDE. If you are unwilling to start from scratch with no third-party components and do some basic trial-and-error you will never know if the problem you are having is Delphi or not. I can say I do simple and complex searching in the IDE every day many many times as I work and I do not have any problems with those features. The most likely difference between my setup and yours is going to be what components we have running in the IDE, so, it's a good place to start.

Right now it's obviously a question of whether you want performance or efficiency. If you want to prognosticate you're going to decide if you think ARM will catch up and surpass on performance or if x64 will catch up on efficiency (it doesn't need to surpass on performance). Regardless, it seems clear ARM is here to stay even on Windows machines.

Yes, we need an ARM64 Windows compiler, unless you think all of these Windows ARM64 machines are just a passing fad. Emulation is only intended to bridge the gap until applications can be rebuilt for native architecture. Whether or not Linux is more urgent depends on what you are building, I suppose. For me, Linux is irrelevant and I would rather have a Windows ARM64 compiler than Linux features. Also, that is not leaked information and does not confirm anything. You're making a big assumption about what that sentence means to the person writing it. It's a safe bet we will eventually get an ARM64 compiler for Windows, but I suspect it is going to come with some caveats. Unless Embarcadero wants to write their own, we are going to have to settle for an LLVM compiler which means our Windows builds will not work exactly as they have for the last 30 years, particularly when it comes to exception handling.

The problem described sounds like what happens when a third-party component is crashing the IDE. Nobody at Embarcadero can help with that issue, you will need to resolve it on your own. Assuming that is the problem of course, but you would need to take a few minutes to figure that out. 🤷‍♂️

How about removing all of your third-party components from the IDE, and adding each one back until you determine which one is the problem?

Anyway it would be interesting to know what the actual problem is that the OP wants to solve. If we're considering really bad ideas, there is an actual answer that could be considered: fork System.Classes, add the desired property to TCompoent, and rebuild everything. Literally everything; you'll have to drop to the command line to rebuild all of the DCUs in Delphi, and rebuild every single component you're using in the IDE. That's a last resort, but it would work. Of course, there is probably a much easier and less brutal way to accomplish the OP's goal, if we only knew what that is.

What could possibly go wrong

The first step is to re-think whatever series of choices led to this abysmal state.

Strings are copy-on-write, but the compiler doesn't do any magic to automatically de-duplicate strings. The only way you get COW efficiency in memory is when you assign one string to another. Some classes have code for deduplication, like TStringList, but you would know if you were using it and it probably doesn't apply to your situation.

You're better off doing something like function myfunc(const InVal: String; out OutVal: Double): Boolean; Return True if the value was set and false if not. There are other ways to handle this but the worst way is a magic value in Double. There's no reason to do that when it is so easy to indicate explicitly whether or not the value is valid.

It only happens if you are running it in the debugger. In such a case, the IDE is very much active and being interacted with; it is not like the program you are running reaches into the IDE and changes something: the IDE is offering to change a setting easily in first-chance exception handling. And this particular feature makes perfect sense and is very much appreciated by me. I'm sorry but so much of this just doesn't make sense. The option in the IDE does nothing except prevent the IDE from giving you a first-chance interruption during debugging. It doesn't change how your program handles the exception.

It only happens if you are running it in the debugger. In such a case, the IDE is very much active and being interacted with; it is not like the program you are running reaches into the IDE and changes something: the IDE is offering to change a setting easily in first-chance exception handling. And this particular feature makes perfect sense and is very much appreciated by me.

Yes, and can lead to all manner of inexplicable behavior if it's not known. If you want to know if you have bad memory, use this: https://www.memtest86.com/ The included memory diagnostics in Windows is completely inadequate, I have had two RAM modules that tested fine with that but showed memory errors with memtest86. So, use memtest86 to rule out bad memory and then you can return to figuring out what is wrong with your code. :-)