Bill Meyer

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.

Over the years, I have used several different report products, and none of them have been what I would consider excellent. I would be curious to hear from others about their experiences. The product I currently use focuses too much on static designs, and we tend to need dynamic construction, instead. My primary concerns would be: Product in active and continuing development Responsive customer support Well suited to dynamic report construction, use of subreports, good graphing, support for RTF, graphics Good documentation, meaning the basics are covered, but real depth on more complex operations At present, I am battling some defects which are a) very hard to reproduce consistently, and b) aggravated by breaking changes across versions. It's hard to clearly identify all the aspects I might call essential, but any of you who have built reports with embedded subreports, user options which affect layout, and dynamic construction are likely to recognize the challenges.

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.

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.