timfrost

The obvious one that you have missed is to use an earlier version of Delphi, that matches the DCU version.

In my case the problem of the inability to select CPU view is related to MMX, but I also now agree with you that GExperts is involved also. I have been experimenting with both the checkboxes in the Delphi IDE key mappings, and the key mappings display in GExperts, and there are inconsistencies. I also tried Ctrl-Alt-D which picks an MMX action, even though Gexperts shows it in yellow.

The Torry listing for this says 'source on request'; and I agree with you about source code. And not seeing a published source price is never a good sign.

Answered on SourceForge (with apologies for believing the original report without testing). It turns out that Ctrl-Alt-C is one of the shortcuts defined and documented by MMX Code Explorer, and is easy to change. And I was pleased to discover the very useful list of shortcut key owners in GExperts, which I had never enabled before!

I have added a bug report on SourceForge

I used to think that the long-time failure of the CPU-window short-cut was an inexplicable Delphi bug, but I have always used GExperts in many Delphi versions. Thanks for identifying the probable source and I second your request for a fix (and the thanks for maintaining GExperts)!

Don't forget to clear the Windows icon cache after you have made an icon change, to be sure that you are seeing what your users will see on first installing your application. Your search engine will find many ways to do this, some of them better than others...

Which version of Delphi are you using? Is this is Rio or an older version?

I regret to say that as a library consumer I agree with Stephan Glienke on this. Instead of a package manager I already have an excellent tool to control all the third-party Delphi libraries we use. It's called FinalBuilder(!), and it does everything I need to build these libraries (and a few of our own) from source, and install all the design packages. This ensures that the source/DCU/BPL/DCP files are all where I expect them to be, not scattered around my drives at the whim of a third-party developer. There is a set procedure I follow for new Delphi versions, and a simple set of changes to make to a cloned copy of the Finalbuilder target for a new compiler and a new main folder of our Delphi source and library folders. For library upgrades, I never install a new library automatically into a production environment (so I will never use a "package manager"). Instead I install the source elsewhere, and first review all the changes with Beyond Compare (and apply our few source changes and fixes if still needed), before allowing them near the production development environment. I find from long experience that this the best way to eliminate surprises on upgrades. Separate targets in Finalbuilder can be conditioned to continue building with the old version, with perhaps older library versions also, while testing the new one. There are a couple of annoying third-party library installers we use, where it is impossible to turn off the 'build' process after install. For these I keep an old VM where I can run the installer, then move the source so that I can control the installation with our FinalBuilder project. For a few .Net applications we have needed, I have used Nuget for third-party libraries. Yes, the source and solution files get installed, and it is possible to modify source if needed (for each upgrade). But that is only possible, I believe, because the development environment has been designed, and Nuget integrated, to make this simple. Nobody could make that claim for Delphi, and that is why having a Finalbuilder project to do all this makes it so simple. I congratulate Vincent for having the vision to try to solve the packages issue for Delphi, but sadly I have to hope that it takes a long time before third-party vendors take it up and try to force me to use it! I do concede, however, that a feature like this would certainly help and encourage new users, and perhaps large teams, to make use of third-party libraries; but for sites with mature applications with a good number of libraries, and who need to manage changes carefully, I can only see new problems.

I found this as: https://quality.embarcadero.com/browse/RSP-23655 I suggest you vote for it (as I have)

And perhaps one more (though tiny): The very useful Warn Directive tool misses at least one warning. I found that COMBINING_SIGNED_UNSIGNED64 (1073) is absent. It might also be useful to have an option in the dialog to show the warning numbers (and perhaps sort on this value). I find that some numbered warnings have a descriptions which does not match the the name, making them hard to find in the list. For example the compiler reports "W1036 Variable 'x' might not have been initialized", but needs USED_BEFORE_DEF to suppress this.

If making a mistake is not critical, just choose any of these algorithms; without knowing the context, and without detecting the language of the surrounding text, they seem about equally risky to me. If you are transferring money, or worse, measuring dosage of medicines, then none of them are of any practical use.