on 2024 Oct 30 9:43 AM
Using Crystal Reports 2020 viewer in my C# WinForm application, after the data is loaded into the report, the RPT is correctly displayed in the viewer.
And, when setting Viewer's PrintMode=PrintToPrinter, and then, click the print button of the viewer, the print-out is also correct. So far so good.
But, this time, when setting the Viewer's PrintMode=PrintOutputController, and then, click the print button of the viewer, the print-out is incorrect!! That is, the top & left margin of the print-out is too much.
Why the viewer in printmode='PrintOutPutController' does not produce the same result as print mode='PrintToPrinter' ??
Or, under the circumstance of setting PrintMode=PrintOutputController, what other measures should I take in my C# code in order to instruct the viewer print output as the same as when setting viewer's PrintMode='PrintToPrinter'??
Request clarification before answering.
Hi, Don,
Thank you for taking time to feedback observation.
You said: "Bottom line is POC is not capable of using your default margins." and "Nothing CR .NET POC can do",
But, I also test the rpt with data using Crystal Report Designer: Open the report file -> Choice "Print" from File menu, and the POC (not PTP) printer dialog pop up, and I again select "Cute PDF Writer" as printer and print.
The content of the print-out PDF is perfect and is the same as print out from PTP mode in your test application.
Any thoughts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There is a difference... let me explain
Crystal Reports is built using Visual Studio C++ and it uses direct access to the DEVMODE structure, that's where Microsoft saves the Printer info.
So in Crystal Designer it directly accesses the DEVMODE structure when printing.
This is the same info SAVED in the RPT file. In Visual Studio using the Edit Report feature it use an Embedded Report Designer called CRAXDDRT.
It's a COM dll that wraps around crpe32.dll, that's the core report engine which uses the DEVMODE structure for printing.
So now the reason you see 2 different Print UI's is because P2P uses the saved info in the RPT file and doesn't use the .NET Printer Dialog.
I forget the actual names of the Printer Dialog dll's...
So when using P2P it uses the crpe32.dll to access the printer dialog.
When using a .NET App the POC API uses the .NET Printer Dialog box which then wraps around crpe32.dll and things are not 100%. Which is why the default margin in POC is .51 inches, note even if you set those values the .NET values is ignored, internally that is the smallest margin POC is capable of using.
The other thing you have to into account is the Custom Paper Size you are using, .NET will attempt to "match" the closest paper size available. It actually queries the Printer to see what paper size is closest to what is set in the Report.
To sum up:
CR Designer accesses DEVMODE structure directly.
CR Basic, which is what the Embedded Report Designer is in Visual Studio uses what is saved in the RPT file.
.NET POC API uses MS's .NET Printer Dialog box which is a .NET wrapper around the DEVMODE structure and is not always 100% compatible.
Also be aware those PDF print drivers are also not 100% perfect, when I worked at SAP I escalated a few issue with CurePDF and MS PDF printer, in all cases it was a limitation of those print drivers.
I suggest contacting CutePDF and explain to them you are seeing the top Margin being increased and see if they can fix their driver.
So again, bottom line is there is nothing CR can do to fix this.
FYI - I used my test app and rather than printing from the CR Viewers Print button I set the printer to my Lexmark printer, change it to landscape, best I could do and selected Legal paper. I did not see the header space as you did.
FYII - I did the same as you and the CR Viewers POC did the same as your test.
Work around, use your own print Button rather than the one built into CR Viewers. There was a test app that turned off CR Viewers print button but I can't find the KBA, it wasn't supported because the Button ID's can change any time..
User | Count |
---|---|
77 | |
30 | |
8 | |
8 | |
7 | |
7 | |
6 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.