Bill Meyer

I'll go with Knuth's opinion. 😉

But then, any high level language is just a collection of GOTOs in disguise. Any instance of a jump instruction in the machine code is a GOTO. Look in the CPU window, and you will see jmp and jz in many places. Moreover, Break and Continue are disguised GOTOs just as much as is Exit. There are good reasons to use GOTO, as has been pointed out by Knuth and others.

But data drives the presentation*. If you are a DevExpress licensee, then you could use their grid with grouping. (But it's still logically a tree.) *See Wirth: Algorithms + Data Structures = Programs

Given the obvious hierarchy, the TreeView seems an obvious approach. You have: Product Process Steps Details, perhaps.... A tree with checkboxes to show progress, and if necessary, a confirmation required for unchecking. The data hierarchy would keep your options open, and the TreeView would keep the UI compact and intuitive.

Thermal wear, yes, but not because of power cycles, which are indeed another stress. The best thing for a drive which runs 24/7 is to remove heat from it. Airflow can be part of the solution, but a more useful approach is to mount your drives between relatively thick aluminum plates. You might also use thermal paste where the drives contact the aluminum plates. I used that approach years ago in video servers where the SCSI drives were rated for 150F max, and if left in free air on a non-conductive bench, reached 149F from their own operation. With the use of aluminum plates and intelligent airflow -- drawn out, not blown in -- we kept things at 105F with no difficulty.

If your processes are stored in a table, and the steps in each are contained in delimited text in the process record, then you could stay with the radio button -- or checkbox -- group model, but easily customize per process. Alternately, you could use master/detail tables to contain the processes and their steps. As to the UI, a TreeList could also be a good approach.

I have learned the hard way that trying to read an old 3-1/2" floppy is perilous. My experience has been that most of them shed oxide which is then very hard to remove from the head. And some of us OGs still have stacks of 5-1/4" floppies (which do not seem to share the shedding problem of their smaller cousins.)

I know. But I'd really like to boot into Ubuntu and run VBox there with one of my existing VMs.

Too easy. 😉 I briefly considered Hyper-V on my main machine, but I have a substantial commitment to VirtualBox and as it does not (yet) play well with Hyper-V, making the change is impractical. My VBox VMs pay the rent, and that trumps other considerations. I have also considered going dual-boot, but that leads into research regarding the UEFI complications with an SSD as my boot drive. And I am not willing to risk creating problems on my primary machine.

Tried to leave a comment on your article. Logged in to WordPress, but the Post Comment button doesn't appear to do the post.... Tried in both Vivaldi and MS Edge.

Pascal Analyzer Lite is helpful; I have not used the full product. It is the only tool I have used which can advise as to uses references which can be demoted from interface to implementation. It does give some false positives, however. The CnPack Uses Cleaner is also helpful, though like Pascal Analyzer Lite, it will give some false positives. It doesn't take long, however, to build a mental list of the modules you can't remove, despite its advice. MMX is great for tabulating unit dependency cycles, and although the report it generates is huge, it is easily parsed, and I have built a simple tool to do that and present in a grid the cycle counts per unit, which is helpful. DUDS is quite fast, and its tree view seems to me to communicate a more useful sense of dependency relations than the Cartesian map in MMX. I have not found any single tool which does all that I could wish. The Pascal Analyzer Lite Uses report is very useful, and for demoting uses references, MMX is far superior to hand editing. Pascal Analyzer Lite is slow, and if your project is large, definitely use the 64-bit version, or it will run out of memory. If you are in a VM, give it plenty of RAM. PAL has used about 2.6GB on the large project I have been reworking. The thing I really would like is to find a tool which can help you discover which modules in dependency cycle chains are villains, and which are victims. In a large legacy project, it is very difficult to identify the modules which are most in need of rework.

An example, then, of memory fade. I must be recalling from D7 days, I suppose.

I think it has always been possible. I remember doing quite a bit with assigned values in enums in D2 and D5, and for the same reason: interfacing to third-party C DLLs. I seem to recall having observed it then.

As a former colleague was fond of saying, the nice thing about standards is that we have so many from which to choose.

I only do occasional graphics work, and Affinity Designer is a more realistic option for me than an Adobe subscription. I am not a graphics designer, but have done quite a bit of graphics work over the years. And I would say that Affinity Designer does make it relatively easy, even for a dabbler, to produce good results. There are many good videos on youtube. I would recommend this one, to start: