Home General
New Blog Posts: Merging Reports - Part 1 and Part 2

Suppressing Print based upon SubReport row count

edited March 2017 in General

Hi there :)

I am using RB 17.02 build 149 with Delphi XE (that's the important
details out of the way, hopefully!)

I am designing a label, based upon a pipeline (from a Stored Procedure
which I can't change) which always contains at least 1 row.

However - only some of the rows in this pipeline may be relevant for
display on the label.

In order to constrain these relevant lines to a specific place on the
label, and to overflow onto multiple labels, I have placed the
"static"/"always printed" fields from the Pipeline into the "Main:
Header" section, and created a "SubReport1" which has a Variable within
the Detail band to show or hide the individual items for each row based
upon a number of scenarios.


When the SubReport is displaying 0 rows, I do not want the label to be
printed. The report will still need to be called, and return back to the
calling application as though the print has been successful, but it
should not print any copies to the specified printer.


Is this possible?

Thanks

Garry

Comments

  • edited March 2017
    Hi Garry,

    The best option in your case would be to prevent calling Report.Print if
    the certain data condition is met to skip printing that report. This
    would involve analyzing the data before the label is printed to be sure
    printing is necessary.

    Another option would be to try to cancel the print job from within the
    report if the data demands it. This method however could be tricky as
    the timing of certain events can affect different aspects of generation.

    I believe option 1 would be a much more robust solution that would work
    for any situation.
    --
    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited March 2017
    Hi Nico,

    Thanks as always for the prompt response.

    I would like to try option 2 first (cancelling the print from within the
    Report itself), as this will keep the report generation process within
    the application common for all report templates we use, without putting
    in specific processing paths within the application.


    If you can let me know what I would need to do within the report that
    *should* cancel the print, I can have an experiment with timings to make
    it work - I just was unsure of whether cancelling the print from within
    RB was possible.


    If that's not possible, then I'll have to look at getting a specific
    path put into the report generation process to skip the report printing,
    but that would be my 2nd choice.


    Cheers,

    Garry
  • edited March 2017
    Hi Garry,

    The issue with the second approach is timing. The only time (event)
    that you could possibly cancel the report before the print job has
    already started is the OnInitializeParameters event.

    This event however fires before the report's pipeline has been opened so
    you would need to manually access the pipeline and cancel the report if
    the data demands it. If you are using RAP, this would need to be done
    in a passthru function.

    The above solution is similar to the first option I gave however it is
    internal so could be used for specific templates only. Something like
    the following...

    var
    lbPrintReport: Boolean;
    begin

    //ValidData() is a RAP passthru function that analyses the
    Report.Datapipeline to determine if the report should be printed.

    lbPrintReport := ValidData(Report);

    if not(lbPrintReport) then
    Report.Cancel;

    end;


    --
    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited March 2017
    Hi Nico,

    If I understood correctly, I can't do this purely from within the report
    template itself, and it needs some coding to be done within the calling
    application anyway?

    So - that's what I've done :) I've just added the checks to the data
    before it gets pushed to ReportBuilder - it means the data is loaded
    potentially and run through twice, but at least it works.


    It will mean I have to create more special cases in future, but this is
    the first case in 3 years where I've needed to suppress printing... :)


    Cheers

    Garry
  • edited March 2017
    Hi Garry,


    Correct.

    ReportBuilder

    Excellent! Pre-processing your data is the best way to go about this to
    ensure your report(s) run smoothly.


    --
    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
This discussion has been closed.