'Screen printer does not support printing' issue

rbuser

We are having an inordinate about of trouble supporting customers that
get the error 'Screen printer does not support printing'. The problem
appears to result from transient printer problems in complex network
environments, and the above error hides the true problem (eg that the
printer is not available).

To reproduce the problem in a test app, put a break point on
TppReport.Print, rename the windows printer, and then let app run. Note
that ShowPrintDialog needs to be set to false.


The problem seems to centre around the following code in
TppCustomPrinter.GetDC:
if (FDC = 0) then
begin
lPrinterInfo.IsValid := False;

{set printer name to screen and get screen dc}
if not(FPrinting) and (FPrinterName <> cScreen) then
begin
SetPrinterName(cScreen);
FDC := GetDC;
end;

end;
(The call stack at the time is
TppCustomPrinter.GetDC
TppProducer.PrintToPrinter
TppProducer.Print)

Our problem is that at this point in time the preceding call to CreateIC
has failed. What we NEED to happen (in this particular case) is for this
failure to be reported (printer name invalid, or what ever error
GetLastError happens to report).
Instead, what happens is that the target printer is magically changed to
cScreen ('Screen') and execution continues - which subsequently results in
the exception 'Screen printer does not support printing.' being thrown.

Is it possible to have Report builder enhanced so either:
when the producer is attempting to print the actual printer is not allowed
to change (code above will not call SetPrinterName(cScreen)).
Or perhaps in the calling code in TppProducer.PrintToPrinter:
if (FPrinterDevice.Printer.DC = 0) then
begin
{'Windows cannot print due to a problem with the current
printer setup.'}
MessageDlg(ppLoadStr(1020), mtWarning, [mbOK],0); Could
this be changed to FPrinterDevice.Printer.IsValid that would test printer
validity without changing it name.

Complicated issue, but I can't stress how much grief this issue causes us.
If we could get at the underlying error it would save us heaps of time
trying to diagnose what actually went wrong.

Thanks.



--- posted by geoForum on http://delphi.newswhat.com

nardmoseley

I researched this, by running a project and then renaming my Windows default
printer. To fix this test case, we will add the following check to the
Producer.PrintToPrinter method. Try adding that check in your version.

if (FPrinterDevice.Printer.DC = 0) or
(FPrinterDevice.Printer.PrinterName = cScreen) then
begin
{'Windows cannot print due to a problem with the current
printer setup.'}
MessageDlg(ppLoadStr(1020), mtWarning, [mbOK],0);

FinalizePrintToPrinter;

Exit;
end;



--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com