Bill Meyer

Indeed, I had looked at the page with his implementation, but failed to open the page with the article. 😞 Multitasking is best done by machine.

See: https://en.wikipedia.org/wiki/Xoroshiro128%2B As the commentary indicates, all PRNGs have some deficiencies, and those may or may not be of concern in a given application. This one is reputedly of high statistical quality, and very fast. I did not find an expression of the algorithm, so there remains the question of whether the implementation is accurate.

Yes. The alternatives were ugly. Although the component supposedly implemented a standard encryption scheme, others which implemented the same yielded different results, and we had to support previously encrypted data in customers' systems.

Had just one experience with it. A former employer used an encryption component for which they had no source. And the publisher of the component was out of business. We needed to move form D6 to D2006, so wrapped the component in a DLL and moved on. Never use a component without source. Never.

You can use the components together, and you can develop comparable styles, but the style classes in different component packages -- and in Delphi -- are different to one another.

http://docwiki.embarcadero.com/RADStudio/Sydney/en/Scoped_Enums_(Delphi)

We're not all on 10.4.1.....

You were, indeed.

Er... "starting to show"??

Not a fan of them, either, but I recognize the reasons they were added. There were also some attempts long ago to implement form scaling, for which the explicits would be helpful. Or would, if such scaling were practical. But it's not (see rounding errors) since we would need all visuals dimensioned in floating point to make that work.

Useful information is here: https://stackoverflow.com/questions/13790953/what-is-the-best-way-to-install-components

Component -> Install Component Browse to file name, and select Install into a new package.

Nor Tokyo. Anyone know when it appeared?

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.