Bill Meyer

I thought I remembered UnitName in some hazy way. But the issue here is that I need to add logging into an initialization section, and not all of those are calling into classes. I am simply trying to find the least change needed to get the log to demonstrate the initialization order. Then I will apply that sequence in a module in which I manage the initialization sequence, and in each module, the initialization and finalization will be replaced by procedures InitializeUnit and FinalizeUnit, which contain the original code. The issue is that the initialization sequence contains some traps, in that there are sequence dependencies, and on the way to a complete solution, making the order explicit in my code shields me from the shifting sands when changes are made to uses clauses. This in turn is a concern because of massive unit dependencies I am trying to reduce. As I learned painfully some months ago, removing unneeded unit references can cause the execution order of those initializations to change. And yes, in the long run, refactoring and redesign is needed, but meanwhile, I have a couple thousand units in a large legacy app which must first be made stable.

I have a love/hate relationship with ReportBuilder. My experience has been that it builds PDFs reliably, and with no quality concerns. That said, when you encounter idiosyncratic behaviors, finding solutions for them can be a nightmare. It is on my agenda to try FastReports, which looks promising.

The only time I have seen issues with image quality was when the provided image was significantly smaller than needed, and it was being stretched the the desired size. That said, I believe that the support for such operations in most graphics components is less than excellent. If you need to enlarge images, you may do well to use graphics32 or similar, to enlarge them before inserting to the report.

The charts I have needed to insert were relatively small, such that three -- the maximum I needed -- would fit on one page. Since there is embedded support in ReportBuilder for TeeChart, I wonder whether that may handle the concerns you raised.

I do this in ReportBuilder. Are you using a reporting tool of any sort?

But the formatter is of little use, if it can be confused by coding style. There are many things I don't do that others have done, and in some cases, I will use a formatter to clean things up, but most of the time, I am dealing with old code in source control, and my colleagues would be very unhappy to see files reformatted. 😉

A dictionary is nice, but in older versions -- I work a lot in D2007 -- then I make use of enums and const arrays. Defining them can be tedious, but maintenance is simple, and associated code is clean and easy. One thing to note on defining const arrays in the private section of a class: In D2007, I have found that defining consts in the class breaks the Ctrl-Shift-Up/Dn navigation between interface and implementation on members below the const declaration. I therefore put const declarations in the implementation section of the unit.

That is something the Delphi Unit Dependency scanner will report. https://github.com/norgepaul/DUDS

Just a small thing, but in the Dependency Analyzer window, the first panel in the status bar could be made somewhat wider. It is truncating the string slightly in my project where there are over 2800 units.

What sort of standards? That word is almost as useless on Google. 😉 But I can imagine all sorts of things I would seek to make standard within an application....

Quite a few years ago, someone wrote a series of articles on how to design forms that were testable in code. I thought it was also a great demo of why you should avoid doing so, as the added complexity was impressive. At any event, I thought I knoew who the author was, and in what magazine they were published, but I seem to have been wrong. A great deal of time on google didn't help. If anyone here recalls the articles, the magazine, or the author. please let me know. Bill

I routinely use Source Export to capture snippets I then insert into MS Word as formatted text. Right now, I am attempting to do the same with Affinity Publisher as the target, but the text after paste is plain, not formatted. If I paste to MS Word, then copy the same block from MS Word and paste to Affinity Publisher, I get the desired result. But obviously, at the expense of more steps in the workflow. Is there some tool I can use to look at the raw content from the clipboard item, so I can get some idea how the Source Export differs from what I copy from MS Word?

These were recommended to me: http://www.freeclipboardviewer.com/ https://nirsoft.net/utils/inside_clipboard.html MS Word, copying to the clipboard, inserts all manner of stuff. The export from GExperts was 3K; from MS Word, 44K. And I have no idea which particular chunk of content may make the difference. 😞 For now, I can export as RTF, paste into an editor and save, then import that to Affinity Publisher.I just discovered that ClipMate, which I have used for years, offers an Application Profile report which suggests in its section on Publisher that the current possibilities are only TEXT and RTF. However, the RTF fragment from GExperts pastes as plain text. If I save it in Notepad, and then Edit, Place (Import) in Publisher, it comes in with formatting, as it should. I am collecting datapoints, but I can't claim to have gained any useful insight.

That aspect you should be able to resolve easily enough with a TStringList as a buffer, and just iterate through the source stringlist from bottom to top, copying lines to the destination.

For reasons I have never understood, the TDataset and its descendants stream data, but not properties. In my own work, I have had to deal with this in connection with the field properties we wish to pass to reporting code. It is all very nice to have Alignment, DisplayFormat, and DisplayLabel, but rather annoying that there is no option to include them in streaming.

Not yet.....

A point not yet mentioned is the use of nested methods in the course of refactoring. In legacy code, it is not uncommon to find huge routines which have been thoughtlessly coded, and often with useless naming. I have found it helpful to remove to nested methods the chunks of code which might better be placed in a private class, as Arnaud suggests. Making them methods of the class in which you are working often makes no sense because these routines may have no practical value out of the context in which they were found. In new design, their use is harder to justify, I think.

Not obvious, to be sure. I am still cursing the new approach, which seems a good deal more complicated than necessary.

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.

This subject came up yesterday at the office. I could not recall what topic it was in Knuth's magnum opus where he explains that although goto can always be avoided, there are rare cases in which its use brings performance benefits. Seems like a sorting discussion. Quicksort?

Oh, yes. you can pass 1..n units. Of course, what you may get, with name collisions -- which will not be reported -- is up for grabs. (Note that FixInsight now checks for with clauses which use more than one unit.)

The inherent dangers of 'with' are at their worst with such usage as: with UnitA, UnitB do.

And that's fine, but doesn't negate it being a bad fit for Delphi, does it?

Nor should we be surprised, as MVVM was evolved into by people working every day in C# and with XAML. This happened, I am told, as people simply found a comfortable approach in that environment, not because they sought to copy an idiom from another language.

Interesting. Had not heard of Rosinsky before.