471,853 Members | 783 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,853 software developers and data experts.

Crystal Viewer and Printer Settings

When i right click on the .rpt file in the VS 2003, i see a property
printer setting.
It says "No printer" on the top and there is option to select printer
and paper settings etc..

I want to know how will this affect a report rendered by a crystal
I have a web page with a crystal viewer rendering the report on the
I build my application in one of my development machines and deploy it
on the server. By default, the printer setting is set as the default
printer settings on my development machine. Everything works fine on my
development machine.

But when i view the report from the server, the page appears shrunk
either in width or in the number of records per page.

Then i rebuilt the application with the printer setting as "No
Printer". Then i checked the report on the server machine. Now the
report is rendered properly. But when i try to print, the printing is
not proper and the web page after printing goes back to the shrunk

Can anyone explain me what is the use of the Printer Setting in the
report file??

Thank you.

Nov 17 '05 #1
1 11798
Crystal's handling of printer settings is, quite frankly, hooped. I
talked to the Crystal guys at the booth at PDC05 and they gave me some
reasons as to why it is this way, but for "normal" corporate printing,
it's just messed up.

In the version of Crystal Designer that comes with Visual Studio 2003,
you have two choices:

1. Choose "no printer" in the printer settings of your report. This
means, "Whatever are the default settings for the default printer on
the machine where this report is rendered, I want the report rendered
to that printer's default page size, orientation, duplexing, etc. etc."

2. Choose a printer in the printer settings of your report. Then you
can indicate that you want 8.5 x 14 landscape printing (for example).
However, this assumes that you are always going to print the report to
the _exact same printer_ in production. Of course, it's "never" like

When you choose a printer for your .rpt file, this is what happens:

Crystal Designer grabs the DEVMODE structure for the exact printer you
specify, and lets you change the DEVMODE settings. That's what you're
doing when you set "Landscape" and the paper sizes. It then stores the
changed DEVMODE in the .rpt file.

When the Crystal Report rendering engine loads the .rpt file, one of
the first things it does is goes hunting for a printer with the _exact
same name_ as the one from which it grabs the DEVMODE structure
originally. If it can't find that exact same printer on your production
machine, it switches to the default printer for the production machine,
and tries to apply the DEVMODE settings from the .rpt file to that
production printer. If the default printer doesn't like the DEVMODE
settings from the .rpt file and mangles a bunch of them to suit its
tastes, then that's just the way it goes.

If you then switch printers in code (by setting a new printer name for
the report document object that you loaded via Crystal), then Crystal
will try to apply the DEVMODE settings to the new printer you have
assigned. However, if the DEVMODE settings have already been thrashed
by trying to apply them to the default printer, then that's just too

The whole thing is set up assuming that you are going to print your
report to exactly the same kind of printer with exactly the same name
on every machine.

We have had some success by making sure that we create printers on our
development box with exactly the same names as they have in production.
However, we have only one production server. People with multiple
production servers may find that this isn't possible for them.

Even if your printers have exactly the same names, you can be hosed by
custom forms. You see, the DEVMODE structure in the .rpt file stores
the _form code_ from the printer, not the name or size of the form. If
you're creating custom forms on your printers, there's no guarantee
that the same form will be represented by form #104 on all printers in
your organization. Since that's what the DEVMODE stores, just 104, you
may end up getting kooky results on one or two printers.

I've complained to Crystal several times about this. To me, it's
ass-backwards: I want to describe the overall shape of my report: paper
size, orientation, duplexing, etc. Then, later, I want to specify a

The response I got at PDC'05 was that the Crystal Designer takes great
pains to make sure that the report appears on the printer _exactly_ as
it does in the Designer, so they grab precise printer metrics and
precise page sizes and fonts, and for that they need the DEVMODE

My answer is that that is wonderful, but most business reporting
applications just want to specify some general things about the report,
and get some good-looking output. I don't _care_ if the text wraps at a
different word on different printers because there's a 1/64" difference
between the page widths. I just want output.

One of the guys at PDC'05 said that he thought this was fixed in
Crystal XI, but I haven't tried it out yet, so I can't vouch for that.

Nov 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Troels | last post: by
3 posts views Thread by Robert Schuldenfrei | last post: by
5 posts views Thread by Robert Schuldenfrei | last post: by
2 posts views Thread by Ralf | last post: by
1 post views Thread by =?Utf-8?B?U3RldmUgQmFya2Vy?= | last post: by
reply views Thread by NeoPa | last post: by
reply views Thread by aboka | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.