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

Check for report sent to printer

edited August 2005 in General
I've reviewed the tech tips on "AfterPrint" etc, and I haven't seen
anything quite like what I need.

Using RB7.04, D7E, Waler TExtraDevices

I need to update a print flag in a database based on successfully
printing a report. Of course the user might
- just preview, then close
- preview, call up print dialog, then cancel
- preview, call up print dialog, print and cancel whilst actually
printing

As well, there may be a print error and print is stopped.

There is the preview window, the print dialog, and the "Now Printing page
nnn" dialog. (How do I access the "Now Printing" dialog to test for
cancel?)

In the following, "PrintTest" means: (ppReport1.PrinterDevice<>nil);

I tried using ppReport1.AfterPrint - it fires after the print dialog
closes (PrintTest is true), AND preview window is closed (PrintTest is
false). Obviously I can set a flag or only trap the value of PrintTest in
PrintDialogClose - but there is another issue - TExtradevices - if I
"print" to PDF, PrintTest is true when print dialog closes.

Is there an example project, or tech tip, that will show me the best way
to ensure that the last page of the report was successfully sent to the
printer? That is, not cancelled, nor sent to a non-printer device?

Also, is there a way to trap what pages were sent to printer? That is, if
pages 1-20 of 100 were printed before user cancelled I'd like to trap
this fact by saving a key value from the pages (e.g. printing work
orders, one per page, trap "work order no" as each page is successfully
sent to printer (and ONLY to actual printer device).

TIA

Cheers,
EdB

Comments

  • edited August 2005
    Hi Ed,

    1. If the user cancels the print process using the Cancel (Now Printing)
    dialog, the Report.OnCancel event is fired. Also you can access the cancel
    dialog using the Report.CancelDialog property if you need to make changes.

    2. You should be able to tie into the TppDevice.OnReceivePage event to
    determine if the last page has been sent to the printer and how many pages
    have been printed to the printer before the user canceled the print job.
    The OnReceivePage event sends the page object as a parameter.

    3. When using the print dialog, you can check the
    Report.PrintDialog.DeviceType property to determine which device the user
    decided to print to (in the case of PDF printing).

    --
    Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited August 2005

    In article <430f1bf0$1@dm500.>, "Nico Cizik \(Digital Metaphors\)"
  • edited August 2005
    In article <430f1bf0$1@dm500.>, "Nico Cizik \(Digital Metaphors\)"
  • edited August 2005
    In article , edwardb@sgci.com
    says...

    Answer to this one - yes. If you "Print to file: Printer File" the
    DeviceType is 'Printer' and PrintToFile=true.

    Here's a summary of logic so far:

    Form private vars:

    FPgSetting : TppPageSettingType;
    FPgRange : TppPageRangeType;
    FDidCancelPrint : boolean;
    FDidSendToPrinter: boolean;

    procedure TForm1.ResetStateFlags;
    begin
    // set stuff to known state between calls
    FpgSetting := psFirstPage;
    FPgRange := prOddPages;
    FDidCancelPrint := false;
    FDidSendToPrinter:= false;
    end;


    procedure Tform1.ppReport1Cancel
    begin
    // make sure cancel dialog visible -not something else triggering cancel
    if assigned(ppReport1.CancelDialog) and
    ppReport1.CancelDialog.Active then
    FDidCancelPrint:=true;
    end;


    Procedure TForm1.ppReport1PrintDialogCreate
    begin
    ResetStateFlags; // because user can preview, print, cancel, print again
    end;


    procedure TForm1.ppReport1PrintDialogClose
    begin
    // must go to actual Printer, PrintToFile not acceptable
    FDidSendToPrinter := ( (ppReport1.PrintDialog.DeviceType='Printer') and
    not (ppReport1.PrintDialog.PrintToArchive) and
    not (ppReport1.PrinteDialog.PrintToFile)
    );
    end;


    procedure TForm1.ppReport1PageRequest
    begin
    // only save settings if PrintDialog is up - ignore screen device
    if assigned(ppReport1.PRintDialog) then begin
    FPgSetting := ppPageRequest(aPageRequest).PageSetting;
    FPgRange := ppPageRequest(aPageRequest).PageRange;
    end;
    end;


    procedure TForm1.btnPrintClick
    begin
    ResetStateFlags;
    ppReport1.print;
    if (FDidSendToPrinter and (FPgSetting=psAll and (FPgRange=prAll)) then
    if FDidCancelPrint then
    DoSomeRollbackOnCancel
    else
    DoSomeCommitOnPrint;
    end;
    ---------------------------------------------------------

    This should help get anyone else started on detecting 'sent to printer'

    Any comments on anything I might have missed - or could do simpler?

    I'd still like to find a way to trap pages sent to printer, and ensuring
    the printer I send to actually still exists - my being paranoid and
    all...

    Thanks.

    Cheers,
    EdB
  • edited August 2005
    Hi Ed,

    Correct, there may be cases where you assign the device to "Printer" and you
    output to a file. As far as printing to a PDF exporting driver,
    ReportBuilder sees this as another printer so PrintToFile should not be
    True.

    If you can get a reference to the device being printed to (i.e.
    Report.PrinterDevice). You can assign the OnPageReceive event yourself.
    For instance...

    ppReport1.PrinterDevice.OnPageReceive := PageReceiveEvent;

    Using this event, you should be able to determine which pages have been sent
    to the device up until that point.

    --
    Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com

    Best Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com
  • edited August 2005
    In article <4313287a$1@dm500.>, "Nico Cizik \(Digital Metaphors\)"
  • edited August 2005
    Hi Ed,

    Now your getting into the inner workings of ReportBuilder :). The process
    you describe below is generally how every device is designed to work. If
    you take a look at the TppTextFileDevice class for instance inside the
    ReceivePage method, you will see how each drawcommand is extracted from the
    TppPage object.

    The first page sent to the device is a Message Page. This page contains no
    draw commands and is simply providing an indication of generation progress.
    The ScreenDevice uses Message Pages to display report generation progress in
    the Print Preview form status bar. You can determine whether a page is a
    Message Page by checking the IsMessagePage property of the device.

    --
    Regards,

    Nico Cizik
    Digital Metaphors
    http://www.digital-metaphors.com

    Best Regards,

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