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

AfterPrint firing too soon

edited October 2019 in RAP
We just finished upgrading to V19 (from V15). In many of our reports we have RAP code that create a temporary memory table and tear-down the memory table in AfterPrint.

This worked fine in V15, and mostly in V19, but we discovered a problem.

If the user prints to Screen, and then uses the Printer button, the report AfterPrint fires once BEFORE printing and again AFTER printing.

In V15 it only fired AFTER printing.

If the user goes directly to printer (DeviceType := 'Printer'), then this behavior doesn't happen and all is good.

I believe this person is attempting to describe a similar problem but got no response (http://www.digital-metaphors.com/forums/discussion/2219/report-afterprint-event-and-report-devicetype/p1).

Is there anything we can do?

Comments

  • Also if this is a requirement going forward...maybe there's a way through delphi (non RAP) to detect if the report has an AfterPrint and disable it?
  • Hi Dusten,

    The events are firing correctly. (There was a bug in a prior version)

    Try setting Report.CachePages True. Then for Preview all the pages will be generated to cache - unless there are over 100. You can use PreviewFormSettings.PageIncrement to control this. With the pages cached, when Printing from Preview, the BeforePrint/AfterPrint will not need to fire.

    Another option is to use CodeModule OnCreate/OnDestroy. (From Calc workspace, select View | Module), then select the Global Events tree node.

    BeforePrint fires each time the report generates to Preview, Printer, File etc. For each BeforePrint there is an AfterPrint. Cannot have two BeforePrint calls in a row. When Preview is selected BeforePrint fires. When Print button clicked and close the PrintDialog, AfterPrint fires (corresponding to preview BeforePrint). BeforePrint fires, report prints to printer, then AfterPrint fires.





    Best regards,

    Nard Moseley
    Digital Metaphors
    www.digital-metaphors.com
  • Ok, roger that. Thanks for the response.
Sign In or Register to comment.