Paper size & "Unable to start the print job. ... security context."

[patrick_simons2]

Hi,

I'm using CR for VS SP34, the local printer is a "HP Color Laserjet Pro M452nw" (with the latest driver).

When printing with POC (_crystalMainReport.ReportClientDocument.PrintOutputController.PrintReport(_pocReportOptions) ) to the HP Printer,
I get "Unable to start the print job. It may not be possible in the current security context."

When printing with P2P (_crystalMainReport.PrintToPrinter(copies, collateCopies, 0, 0) ) to the HP Printer,
I get "The data area passed to a system call is too small."

After some research I found out that _not_ explicitly setting the paper size in _pocReportOptions causes the problem.

The default paper size in the printer driver is A4.
The default paper size in the generic report is A4 (with both "no printer" and "Dissociate Formatting Page Size and Printer Paper Size" checked).

If I don't set the paper size, the value of _pocReportOptions.PaperSize remains on CrystalDecisions.ReportAppServer.ReportDefModel.CrPaperSizeEnum.crPaperSizeDefault.Then on the PrintReport, the error is raised.

As Don explained some time ago, there is some printer info stored inside the report file and as "No Printer" is checked, there are some matching tests internally in CR. Maybe here comes a bug?

I can reproduce this behavior with Don's test solution (RAS2010_Printing).

If I change the no printer flag in the report (uncheck + check - so nothing changed), save the report, then the error has gone away - strange... In any case, it would be appropriate to get a clearer message text...

If I use another printer, it works fine.

Thanks for any explanation.

Patrick

[patrick_simons2]

Hi Don,

I just returned from holidays, so I want to dig again in this subject.

btw. did you nevertheless contacted R&D to see what they think about? You got an error trying the test app, perhaps something for R&D they could focus on?

btw2. you have to understand that printing with CR isn't always that easy. When customers are reporting problems, they say that our software has a problem, but never with Microsoft Word or Excel....

Don: "So if No Printer is saved in the Report then you need to use the Clone API to set the printer info if unique printers are required than from the original design Default printer properties.... So what you could do is define a few typical printers, set the dummy report by name, so use a basic generic HP printer, don't use one of Microsoft's default printers, they have limitations also"

We always use No Printer checked for our generic reports, of course there is a default printer on the development PC, but our customers have different printers, and we never know them in advance. So I don't see what dummy reports we could prepare.

Don: "Another option is you could name the reports with the Printer name, check the Customers Default printers used and then set the Printer to their printer and load that dummy report"

We have one ERP that has over 1000 reports, so no chance to deploy them in variations of possible printers.

Sometimes I'm asking myself why MS Word has "never" problem while printing, but CR does a lot... Has the concept on how CR is printing never been reconsidered....? Did you never discussed with R&D about that?

Don "My question to you is did you test using Set Printer to that HP printer and calling the routine to see if it generates any errors?"

I know when using Set Printer with setting the papersize (see first item), I got no error - but that was the original question.

It's a difficult topic...

Thanks again,

Patrick