Check for report sent to printer
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
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
This discussion has been closed.
Comments
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
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
In article <430f1bf0$1@dm500.>, "Nico Cizik \(Digital Metaphors\)"
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
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
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
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
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com