Bill Meyer

9 minutes ago, Fr0sT.Brutal said:

AFAIU, the only truly reliable way of detecting excess uses is removing each used unit one by one and try compiling. But even then there are possible false positives when something useful happens in unit's init section.

Anyway I doubt this task is required frequently so slow process or some part of false positives is quite acceptable

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.

34 minutes ago, Uwe Raabe said:

If you can provide reproducible test cases, you should send them to Peganza. They are always interested in cleaning out those glitches.

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.

18 minutes ago, Uwe Raabe said:

It might be worth to investigate in interpreting the output of Peganza Pascal Analyzer Uses Report and act accordingly. This would eliminate the burden of analyzing the code.

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.

3 hours ago, sLesage said:

I've actually been using a similar approach too. But as a Delphi Consultant I've seen very strange things already ... The order of the Uses clause might actually be important especially when some variables or other things get set up in the Initialisation section of a unit. Oh and @Uwe Raabe any news on the tool ? Been searching for a good tool which can detect unused units / restructure uses clauses for a while now.,

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.

1 hour ago, Rollo62 said:

Apple is no normal business, but a religion.

https://www.worldreligionnews.com/religion-news/is-apple-a-religion

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.

42 minutes ago, haentschman said:

which?

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.

2 minutes ago, Uwe Raabe said:

That is the same in VMware - one file per virtual disk. Each virtual disk has a setting where you can decide if the disk shall be split into several files or just one. The default is split, but I prefer it the other way.

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.

22 minutes ago, Uwe Raabe said:

That is the first setting I am changing for a new VM.

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.

1 hour ago, Dany Marmur said:

I see, @Mike Torrettinni, tanks!

 

Just visited a client where the IT-admin uses WM-Ware. In his opinion WM-Ware works better than VirtualBox. Anyone having that "general" experience too? I'll make an unscientific test.

I think my problem is that i have two "Monitors" side-by side on my one physical screen. I can verify that when i get back to my workstation in a week.

If that's the case then i'll put an old cheap 2nd screen beside my 1500€ super-thingy. But if 4K (the res of the super-thingy, no scaling mind it's huge) is the problem then i'm a bit in a pinch.

Perhaps WM-Ware comes with better screen handling for my comb of host-guest.

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.

6 hours ago, dummzeuch said:

Have you tried Remote Desktop yet?

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.

29 minutes ago, Dave Nottage said:

I think they have code for retrieving the paths somewhere inside CnWizards: https://github.com/cnpack/cnwizards

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.

6 hours ago, Sherlock said:

There is a german saying: Kaum macht man es richtig,funktioniert es. It roughly translates to: As soon as you do it right, it works. It is all too true for most everything 😄

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.

38 minutes ago, Lars Fosdal said:

So many apps today no longer follows the Windows Theme color settings.  That annoys me.

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

17 minutes ago, Mike Torrettinni said:

This is not working if I need to use any methods from TranslatorUnit in Unit1 or Unit2. MMX Unit dependency analyzer shows cycle: Unit1 -> TranslatorUnit -> Unit1, even if all uses are in Implementation section.

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.

50 minutes ago, Mike Torrettinni said:

I don't envy you, at all. I'm cleaning up my own code and it takes a lot for each unit, form, especially if redesign is needed. The easiest is decoupling forms, but some redesigns take time, too much time.

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

9 minutes ago, Mike Torrettinni said:

What is the purpose of keeping {NoLongerUsed,} in the uses clause? If it compiles, it can be removed, right?

 

Also on StillMore {Why here?}, ... why would there be such indication? If it doesn't compile without StillMore then it should be there, no?

 

I don't understand these concepts, I only set those units in uses clause that need to be there. I follow compiler and hints what needs to be there. If it compiles without units, I don't put them there.

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.

4 hours ago, Fr0sT.Brutal said:

That's exactly the scheme I came to. I also avoid using units in impl. section except for app's forms.

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.

5 minutes ago, John Kouraklis said:

So, they can't be swapped designtime? I need to it in code?

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.

8 minutes ago, David Schwartz said:

I prefer VirtualBox to the others.

Agreed! And CloneVDI is indispensable.

1 hour ago, David Heffernan said:

I wasn't suggesting that removing forms was the ultimate solution. I'm giving you debugging tips. At some point, you'll have to do some debugging. And no, I don't mean debugging with the IDE debugger. 

I understand. I have been pursuing a number of possibilities, but ultimately, someone else will make the call about how we address the problem. The mass of modules and the tight coupling in the project obviously need to be corrected, but that is a long path, and the issue, as always in a commercial enterprise, will be decided by managers whose appreciation of the factors may be less complete than one might wish.