Bill Meyer

And they are back. 😞

CnPack does a quite job of finding those which are not needed. Pascal Analyzer Lite does a good job identifying those which can be moved down to implementation. As the the frequency or magnitude of the process, it depends on what you are doing. In my case, a large legacy code base needs cleaning. That becomes tedious, and false positives are not "quite acceptable." After a hundred or so modules, however, it's easier to overlook them.

"Never" breaks down? Arguments are never won with hyperbole. Yes, there are people who claim Macs don't break down, but in my experience, those claims are pure fantasy, and will bear no scrutiny. As to laptops, I know of nothing which loses value more rapidly, regardless of brand. The investment value of a computer is a function of what you are able to do with it that earns value. Computers in general rabidly lose value, and lap[tops are the aggravated case of the class.

I have had some correspondence with them. At present, the problem is that the project is huge, and some of these issues depend on third-party components, as well. One example I have already communicated to them is with respect to DevExpress components, where there are numerous units involved in various features, such as look and feel, which they identify as removable, but which are required. It is not a huge issue, and CnPack is similarly confused by DevExpress, so I generally remove them, and the file save puts some back in.

I can attest that the Peganza Pascal Analyzer Lite Uses Report has been very helpful. Note, however, that it is by no means perfect. 1. It seems always to report falsely that a class helper unit is not needed. 2. It tends to suggest removing units which are actually needed. 3. It sometimes asserts a unit ref can be in implementation, when the IDE wants to replace it in interface. 4. Form inheritance complicates the issues. That said, it is the only tool I am aware of which provides assistance in finding which unit refs can be demoted to implementation. For removal of unused units, I prefer CnPack, which does a test compile, and works with the map file, I believe.

I solved the initialization issue by logging to find the order in which the initialization clauses were fired, then replaced initialization and finalization with procedures which are called from my own initialization unit. Still much work to be done on the uses cleanup, and the untangling of dependency cycles, but I no longer have to worry over initialization stability.

I have believed at least since the original Mac arrived that people who buy Apple gear defend it as much as anything to rationalize why they paid twice what I did -- or more -- for equivalent power. Now I grant that Apple has doe some very good design work, but when I consider a laptop, I see before me an expensive toy. And no matter who made it. Computer hardware has a short half-life. Laptops have the shortest, other than the life of mobile devices. A laptop, even a Macbook, may be a good investment, but the value is more in the impression it makes than in the intrinsic capabilities of the device.

Crystal Reports, ReportSmith, Rave Reports, QuickReports, ReportBuilder, and one or two others whose names do not come to mind now.

Actually, the potential to split is in VBox, too, I think, but I never considered using it. What drives me crazy in VMware is all the little files in the caches folder subtree.

In what way? I am accustomed to VBox, where I usually have a VDI file for my C:\ drive, another for S:\ (our local convention for source), and in some, a third virtual drive for local data.

I sometimes use VM-Ware, and my main complaint with it is the plethora of files it creates. VBox is much simpler to manage. That said, I have not done any critical comparison for performance, but with our very large and slow-building project here, the build times reported by those on VM-ware correlate closely to those we see on VBox. One reason I prefer VBox is that the video driver in VBox has always seemed to be a better design. When I tried VM-ware years ago, the finite choices in resolution offered at that time were purely unacceptable.

The limitations on RDP are very sad. I understand in Windows 7 that Ultimate was a requirement for multiple -- not spanned -- monitor operation. Not happy with it, but at least it was a clear policy position. With Windows 10, I have searched and searched, and have yet to find any clear statement as to multiple monitor operations with RDP. Surely it can't require such specific language to reach a clear answer? I do all my dev work in VMs, and always have multiple monitors available, but spanning is worse than useless, when a window maximizes to the spanned desktop, and screen-center dialogs are routinely split between screens. Historic limits on the functionality are understandable, but with the great proliferation of high bandwidth connections, we really should have better functionality available.

Likely so, but whether it is interwoven with other modules is an open question. I have looked in there before, and too often found things which would be nice to borrow, but hard to mine.

I am working on a large legacy project, and recently encountered an unexpected failure. We added a new form, did a full build, and ran the program in debug. It showed some activity, but returned to the IDE, as though the app had shut down, and it never reached the splash screen. Running the executable outside the debugger, it reports an AV, then when you close, it reports runtime error 217. If EurekaLog is enabled, no elf file is produced. Some searching online shows that the error in question occurs before exception handling is set up. Removing the newly added form, the app builds and runs as normal. Adding a new unit, with no code, also provokes the total failure. I am at a loss to know how to discover the real problem. Any thoughts would be welcome.

When you are dealing with a large legacy project, however, untangling years of ... interesting ... coding takes time.

Update: I have now completed a massive set of minor changes, affecting over 1400 units. Removed all units from uses clauses which were not needed, and demoted from interface to implementation, where possible. The other change was to add a module to manage unit initialization, rather than leaving that to Delphi. All initialization and finalization clauses have been replaced by procedures. That should leave us less susceptible to sequence issues as we continue to resolve the coupling issues. In the process, also reduced by about 25% the unit dependency cycles identified by MMX. And in my VM on an SSD, the time for a first full build after loading the IDE dropped from nearly 4 minutes to about 40 seconds. Progress.

On the good side, they don't support pink goggles, either. 😉

I can't switch projects right now, but in my case, I have a module which follows the form I outlined above from memory, and with over 100 units in the implementation uses clause, and all of them referenced by code in the implementation section, MMX reports no cycles.

Unit dependency cycles are bad. Period. One possibility to consider is that of placing all of the units you access into the implementation section. So, for example, if your TranslatorUnit is laid out something like this: unit TranslatorUnit; interface procedure TranslateAll(const ALanguage: TapLanguage); implementation uses Unit1, Unit2; // your list of used units here procedure TranslateAll(const ALanguage: TapLanguage); begin // code here to perform the translation work. end; end. The basic idea is that none of your application units need to be in the interface section. They need to be referenced by the translation routines, but if they are not specified in parameters of interfaced routines, can be declared in the implementation only. I have a module which is built in exactly this way. Although many of the units in the uses clause remain tangled in unit dependency cycles, this new unit participates in -- and contributes to -- zero dependency cycles.

It's not always fun. 😉 But it is a continuing challenge.

Legacy code is its own excuse. Whatever the reasons may have been, these are examples which exist now, and which I need to parse out without damage to the rest. With over 2,000 units to process, and most containing uses clauses in both interface and implementation, the why of what is there is not my concern. Cleaning is my focus. And NOT by hand.

Actually, I find it is better to add references in the implementation section, if they are not needed in the interface. Unit dependency cycles should always be avoided, but there are tools which can help you with that (MMX, Delphi Unit Dependency Scanner), and the need for such cycles is always indicative of design problems. In general, keep scope everywhere as narrow as possible.

In 10.3, I just created a new app, placed a TFlowPanel on the form, then dropped in a few buttons. I selected a button, and in the ObjectInspector, I find ControlIndex. On Button1, it is zero. I change it to 1, and Button1 now moves to the right of Button2.

Don't they have a ControlIndex property added at the bottom of the Object Inspector? If they do, that's the way to control the ordering.

Agreed! And CloneVDI is indispensable.