Bill Meyer

Yes, an obvious alternative. Was just hoping someone may have gone down that path already.

Interesting. I've been very happy on VBox, and the changeover would be tedious, but the main thing holding me back would be that VBox apparently does not work well with Hyper-V enabled, so it is one road or the other. In my work, graphics play no part, so I have not seen any reason to be unhappy on that score.

Another suggestion I offer is that when you must evaluate more than a few terms, it can be helpful to make use of local variables. This is especially true where each of your terms is itself lengthy, such as SomeObj.SomeMember.AProperty. Similarly, if several terms evaluate properties in a complex object, then rather than writing: if SomeObj.SomeMember.TermOne and SomeObj.SomeMember.TermTwo and SomeObj.SomeMember.TermThree then You might instead do: var obj: TMySubClass; begin obj := SomeObj.SomeMember; if obj.TermOne and obj.TermTwo and obj.TermThree then I also find that with many terms and long reference names, the odds of making errors in precedence increase rapidly. And the reason for that is that the mess in front of your eyes is approaching incomprehensibility. 😉

My roots were in hardware logic. Excess terms in hardware translates to using unnecessary parts, each with a measurable cost. Logic reduction is as important in software as in hardware. We don't see a hard cost for the unnecesary terms, but the cost is there, nonetheless. Look at the simplified form Lars presents. Not a big deal in small cases, but in complex chains of logic, failure to minimize becomes a maintenance issue; it impedes understanding.

You appear to assume that this environment will continue to be viable as new versions of Delphi roll out. Unfortunately, the prevailing assumption in the development world is that a) memory is cheap, and b) it is measured in GB. Even without generics, the difference in an application built in Delphi XE and Delphi 10.2 is huge. In the case of a small app of my own, XE produced a 3MB executable, while 10.2 was over 70MB. These numbers are not horrible, but in the context of Windows 2000 treated as an embedded system, I think you are nearing the end of the line for those old systems. You may buy some time by avoiding generics, but sooner or later, you will hit a wall. In a system where your available resources are soldered into the product, you may well need to support a version for those systems which builds in an earlier version of Delphi, and perhaps cannot acquire the same new features as your main application.

I need to replace components in a large project. Have not previously tried to do this with GExperts, but routinely use it in single forms. On trying to run against all forms in the project, I got this error: The total count of the target components was 193. After the failed replace, it was 146, so has done some of the work before failing.

This may be worth exploring: https://torry.net/quicksearchd.php?String=joystick&Title=Yes

Spent a bit of time with your source. So far, it appears to correctly handle some of the thornier issues which we have in our legacy code. I do need to do some additional testing, and find my way to some of the settings, but what I see so far is very encouraging.

From Primož Gabrijelčič's latest book: vs.

Perhaps there has been some change over versions in when the desktop save is accomplished. In D2007, where I spend a good deal of time, the behavior I described is so consistent that I sometimes treat it as a feature.

If you found it necessary to kill Delphi, then the desktop would not have been updated, and on the next open, the files presented would be from the last saved desktop state.

I think we all recognize that our skills evolve. And so does our thinking. Moreover, today's "best practices" will someday probably be superseded. Any non-trivial code can be improved.

If I get out from under some of my other tasks, I will. My TODO list is a bit long at the moment. 😉

Is it not true, though, that they both refuse to tangle with comments -- and compiler directives -- in the uses clauses? That is an issue for the couple of thousand modules I need to process. And yes, it is a less simple problem than it looks. I spent some time on it, and was not willing to spend more, as I have other priorities which demand my time.

Perhaps I should have said "disappointing" defect repair. Although there has been some renewed effort in the last year or two, there remains a long list of issues, some of which have been around for a very long time.

Have you followed the last decade of uneven support efforts?

On https://blog.dummzeuch.de/experimental-gexperts-version/gexperts-1-3-15-experimental-twm-2019-11-23/ The links now resemble: https://www.virustotal.com/gui/file/22eb6503c8011a347a54a98f2ff62719eb4bc0bf5a5ebe1d62aeb5da90e53b89/detection Nasty stuff.

I see. I guess I was moving too quickly and didn't read your notes.

I have seen the basic message before, but this one leaves me scratching my head: [DCC Error] E2161 Warning: Duplicate resource: Type 14 (ICON GROUP), ID MAINICON; File D:\MyProj\MyProg.RES resource kept; file D:\MyProj\MyProg.RES resource discarded. The file kept and the file discarded are the same file?

I have found that Shift-Ctrl-Alt-Up/Dn is a great benefit in dealing with large uses clauses. But as well as it works on the desktop, it does not function at all when I am on RDP. Whether this is a consequence of something in RDP which could be altered, I have not discovered. I wonder whether this is a known issue.

I see. I have been conditioned to expect top of category pages to be empty, so had not looked at that one. Thanks!

I did not find a way to do that, short of editing the registry entries directly. Is there a menu path I have missed?

Yes, and has had for some years. ;)

I don't recall this happening before, but I add a module to the project, and a {$R *.res} is added to the tail of a unit in the DPR. And it has happened now a few times. Hopefully, restarting the IDE will clear that mode.

Is there any way to refer to the unit name in the unit's code? The question arises in connection with logging, and the convenience it would bring not to have to manually enter the unit name in those calls. Something like: LogThis(ThisUnit, SomeValue); If this were only an occasional need, it would not matter, but I have hundreds units into which to add the calls.