Crystal Report Viewer - Print Button slow in PrintMode PrintOutputController

[patrick_simons2]

Hi Don,

I'm using the .Net Viewer with CRVS2010 SP23 in our ERP program.

Last week one of our customer complained about the print button in the viewer - it took one minute till the print dialog window appeared:

So my idea was that they were some old printers being no longer active, and indeed there were some printers I have to delete. So far so good.

But there was also one printer out of toner. I wrote a little .net program to access some infos about this printer (with OpenPrinter - API of winspool.drv, and also with System.Printing.PrintQueueStatus) - here it took 45 seconds to get the info back from this printer!

Then I tried to change the PrintMode of the viewer back to the old PrintToPrinter - here the Print dialog appeared directly after clicking on the button:

When I select the printer not available (Brother HL 2240) and click on "Einstellungen" (= Properties), I have also to wait this 45 seconds.

And so does also Microsoft Word. After pressing Ctrl-P the print window appears directly:

And when selecting the Brother printer making the problems, I have also to wait in MS Word for 45 seconds (some controls are disabled - plus the message "Connecting to the printer..."):

So in a nutshell my question: why is the viewer in printmode "PrintOutputController" browsing all the printer properties? Neither Word or PrintToPrinter do this.

ER: please only go searching the printer properties of a single printer if this printer is selected in the printer dialog.

Something for SP 24?

Regards,

Patrick

[former_member11696 · Accepted solution]

Hi Patrick,

P2P using just the Framework printer common dialog box and is at it's simplest form, meaning it just sends the job to the printer selected.

POC uses a COM dll to get the printer info using the C++ Windows Common Dialog box. It is much more interactive and in CR it has logic to get get the printer info and see what it is capable of doing, it uses the DEVMODEW structure.

So if you want to compare write a test app in C++ and use the Windows Printer Common dialog box using the DMExtra properties of the printer in DEVMODE and see what happens.

The delay is likely also in Crystal Reports Designer, did you try it there?

If you set the printer to a real printer that is installed does it work without delay when updating the printer properties before the report is previewed?

So I don't think it needs to be an ER, jsut a change in work flow.

Don

[patrick_simons2]

Hi Don,

I'm not asking CR to fix printer issues, but to handle possible printer problems in a smarter way, like Microsoft does it in MS Word (see screenshot above).

So in PrintMode POC, if your dialog window pops up: instead of reading all printer infos directly when filling your list, only retrieve the printer infos when a single printer is selected in your print dialog printer-combobox.

If it wouldn't be possible as ER, I have to switch back our ERP into the older Viewer-PrintMode P2P.

BTW. you know: customers are always complaining about obvious facts. If the response time somewhere in a program is slow - the program will be titled as slow - and as they even don't know CR - they don't care if I would say : ok, Crystal Reports has a problem handling slow printers - they want to get informed (in this case) that a specific printer has problems (Microsoft greys out some controls and puts an info "Connecting to a printer - please wait...") - this would be intuitive.

Please ask R&D what they'll think of...

Patrick

[former_member11696]

So what you are asking for is a fix for Printers that have issues, low on fluids etc.?

That won't happen, it's not our place to fix 3rd party dependencies. Ask Brother to fix their driver so it responds quicker.

We did this back in CR 8.5 and previous versions, we had so many hack work arounds to fix Database client issues we removed them all in CR 9 and simply pass the error through to the user, they need to fix their drivers. It became a nighmare sending out patches to work around the issues and impossible to manage, if they fixed their client then we had to undo the fix we did plus QA and regression testing etc. It's simply too expensive to work around third party bugs.

Same thing with printers, it all works fine if there are no issues with the printers, if there is a problem with the printer, fix the problem, then CR P2P and POC work fine.

Don

[patrick_simons2]

Any guru out there?

[patrick_simons2]

Hi Don,

First to clarify: to reproduce a slow printer is very difficult - I tried it here in my office without success. I only have a slow printer at customers side - and yes, the printer is available, it only takes 45" to get an answer. Maybe network problems... - who knows. So it's not common but it could happen that someone has a "slow" printer.

I'm wondering that CR in POC mode uses "C++ Windows Common Dialog" because your dialog has much more features - like the saved printer or saved paper size infos... - than the standard C++ Windows Common Dialog.

I think the problem is not really the common dialog, it's accessing DEVMODE. I had a similar problem using the OpenPrinter-API (winspool.drv). The method System.Drawing.Printing.PrinterSettings.InstalledPrinters() lists all available printers and also the slow one, without any problem/delay. But when I call the OpenPrinter-API (or also System.Printing.PrintQueueStatus) for the printer in question, it takes really long (also 45") to get an answer back.

Here what Microsoft says to a similar problem:
OpenPrinter

"Note that this approach will block while waiting for the round-trip network communication to the remote printer, so it may not return immediately. How quickly this function returns depends on run-time factors such as network status, print server configuration, and printer driver implementation - factors that are difficult to predict when writing an application. Therefore calling this function from a thread that manages interaction with the user interface could make the application appear to be unresponsive."

So I would ask R&D to open the POC-dialog without querying all printers directly while loading the form. Only when selecting the printer in the combobox, they should query more details from the printer driver (so does Microsoft). Or another option: put the DEVMODE-logic in a separate thread.

BTW. I didn't tried CR Designer on customers side.

Patrick