Best practice for code in inherited reports

I've just begun my first set of inherited reports, and the base report has a lot of supporting code, but when I inherit the report and add an event handler for a new object, all of the code is copied and no longer inherits from the base report. If I end up having a whole bunch of inherited reports, I could end up with many many duplicates of the base code that may need to be updated at some point. It seems that I'm doing this wrong.

What's the best practice for setting up inherited reports that have event handlers for the base report?

Comments

  • PolomintPolomint Australia
    edited 3:33PM
    griffyn wrote: »
    the base report has a lot of supporting code
    One question: is the code in Script within the Report, or Delphi/C++ code in events?


    Our main app has 25+ reports all inherited from a common base FR3 (so Report Headers and Page Footers, Fonts etc. match the App's Style Guide).
    We don't use Script, but do a lot of processing in Delphi Before (and After) Events. Each Report is contained in its own Unit, which is itself a descendant of a base module. We even have a second level of inheritance to support Chart Reports, and Composite Reports. A global Unit contains all of our Export functionality as well as sundry "helper" Functions and Procedures.


    It took a while (a lot of trial and error) to get it right, but now new reports can be created very quickly, and global changes are "a breeze"!

    One trap: the Units that define the first and second level Templates have to be open in the IDE all the time, otherwise Delphi throws a lot of errors / exceptions, and can make damaging changes to DFM etc. if we open one of the derived Reports.

    Cheers, Paul
  • edited 3:33PM
    Polomint wrote: »
    One question: is the code in Script within the Report, or Delphi/C++ code in events?
    Hi Paul,

    I have the code in PascalScript via the Code tab in the report designer. I'm aware that I can link to functions within Delphi, is this the way to go?

    Or should I just rewrite all the Pascalscript as code in a TfrxReport.OnBeforePrint event handler? I presume I can access all the report objects in the same way as I can? I take it this is what you've done in your case?
  • PolomintPolomint Australia
    edited 3:33PM
    G'day Griffyn,
    griffyn wrote: »
    I have the code in PascalScript via the Code tab in the report designeaware
    That's what I thought. I don't know how easy it is to handle inheritance with PascalScript. Perhaps GPI or another Forum user can help.
    griffyn wrote: »
    Or should I just rewrite all the Pascalscript as code in a TfrxReport.OnBeforePrint event handler?
    Rewriting is daunting, but (as in our case, where we rejigged stand-alone reports) can pay off later. Again other users experience may help you, because we never went down the PascalScript path...
    griffyn wrote: »
    I presume I can access all the report objects in the same way as I can? I take it this is what you've done in your case?
    We've never had any problem accessing Report Objects. You just have to remember to "instantiate" the ones you need in the Delphi BeginReport event.

    I'll attach a redacted version of our Template Unit / Form when I get back to the Office...


    Cheers, Paul

Leave a Comment

Rich Text Editor. To edit a paragraph's style, hit tab to get to the paragraph menu. From there you will be able to pick one style. Nothing defaults to paragraph. An inline formatting menu will show up when you select text. Hit tab to get into that menu. Some elements, such as rich link embeds, images, loading indicators, and error messages may get inserted into the editor. You may navigate to these using the arrow keys inside of the editor and delete them with the delete or backspace key.