Brandon Staggs

I use Help & Manual. For deployed help file I use their e-reader format which is basically an executable wrapper around the Trident web control that exposes the help html. I also deploy PDFs and web-based help with it. I think it checks all the boxes on your list. Check it out. I think Microsoft really dropped the ball on integrated help. It used to be so easy and straightforward just using CHM.

Not just you. Regardless of the variable state at the end of the for loop, a while or repeat loop would be far more clear IMO.

A clipboard history is a convenient way to see lots of passwords in plaintext. Who wouldn't love that.

No, but because Windows machines cost so much less for substantially the same thing. The fact that I build my own machines is not really the point; I don't believe most Windows machines are dead in 3-5 years, that's ridiculous. Nearly everyone I work with is using Windows machines at least that old. If you prefer MacOS that's certainly fine, nobody can criticize you for that. My personal experience as someone actively doing development for Macs is that it is easily the worst system to target for development and gets worse with every major update. Although it may be a lot of Unix under the hood, Apple is locking it down more and more with every update. Apple behaves as if it owns not only its hardware but their users. The Apple Tax is not just overpaying for hardware, but losing personal computer sovereignty with every update. It's bad enough on Windows, it's many times worse on Mac.

One of the supposed benefits to an EV cert is that it comes with instant SmartScreen rep. My own experience was than the first time I signed with my EV cert nobody saw any SmartScreen warnings, which was never the case when I first used cheaper certs in the past. Do different browsers use their own screening systems? Windows + Edge should be consistent, but maybe other browsers don't care what SmartScreen thinks?

Sounds like a very poor choice of computers, then. I have like four or five Windows PCs in my house all being used that are 5 or more years old. But, I did build them myself. The cost of Mac computers is outrageous. I am forced to buy them for development work, but unless you are or want to be in the Mac ecosystem, the prices are just too high. This is par for the course with Apple products since the 80s, they have always been overpriced but catering to a subset of the population that buys into their marketing. I will say that modern Mac computers are almost works of art from a hardware standpoint and I guess I understand that for some people this justifies the price, and for others MacOS is better suited to them and you can only legally use their OS on their devices, so.

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