We are using NT 4.0, CR 5...108 Pro and VB 5.0 Pro.

I am using the Crystal .OCX to run Crystal .Rpt files which we have
already defined.  This works fine,
including directing the report to a different printer by choosing it
at run time.  In the VB code before running the report I set the
OCX.PrinterName, .PrinterDriver and .PrinterPort.  (The printers are
actually attached to an NT server.)

I am now working on an application which will run on an NT server and
print to a user-selected printer
attached to that server.  The user selects the printer in one
application and a different application runs
unattended on the server; thus, using .PrinterSelect will not work
because there is no user to do the
on-screen selecting.

This works for some of the reports, however I have not been able to
set the paper size to Legal and/or the
orientation to Landscape.  In Crystal's KB is an article "Printer
orientation problems within an application".  (It is not dated and
does not say what version of CR it is referring to.)  It says that if
you are using the .OCX (not PE API calls) to print the report, then
"The only way to ensure the report prints with proper orientation is
to set up the specified printer driver in Control Panel with the
correct orientation and make this driver the default printer prior to
printing the report."  That would require user-intervention no a
report-by-report basis.

I am trying to use VB code to set the default printer to the one I
need to use and then set
Printer.Orientation and Printer.Papersize.  It does set which printer
to use and the Crystal Report prints
there, but it does not use the orientation and papersize I set.

The CommonDialog control, with .DefaultPrinter set to true will allow
setting orientation, etc., on the default printer.  However, I do not
see any way to use it without user interaction.  Is there.

Is anyone doing this?

Thanks.

Marvin Bergeleen

Hello Marvin,

I've been trying to do this aswell and am having some of the same
difficulties that you are! I haven't been able to discover a work around
for this problem with the ocx, but if you are willing to use the engine
then Thad Thompson wrote an article in VB Magazine a couple of issues ago
addressing this very Issue! I haven't had time to try it out but the
source to his article is available for Premier members at www.windx.com!

Hope this helps!

Marvin,

I guess you must have tried using the (infamous) VB printer object
- bad enough under VB4, said to be impossibly buggy under VB5.
No luck there??

An alternative (that I have not tried myself) would be to dig into
the Windows API to control the printer (devmode structure and
associated calls) - there is some freeware code floating around at
some of the VB shareware sites to do this.

What we have done, in the situation where there are only a small
number of reports involved, is have separate .rpt files targeting
specific printer bins/paper stocks/orientations. Not elegant, I know.

If you find a way please let me know.

Regards,
Les Schmalzbach
(remove nospam- to reply).

Les,

Please see my response interspersed below.

        I thought I remembered your posted this before.  In this case
        we could eventually have 30 to 50 (physical) printers defined
        on the server, then multiplying that by the setups per printer,
        we would have an enormous number of "printers" defined.
        Thanks, though.

        In the MS KB we found article Q105839 on setting the default
        printer.  However, it was written for VB3 and Windows versions
        2.0 and 3.0.  It uses WriteProfileString("windows","Device",
        [then printername, driver and port]).  I am willing to try that,
        using SaveSetting instead of WriteProfileString,
        but using Regedt32 and searching for keys, I cannot find
        "windows","Device".  In other words, I think the keys changed
        for NT 4.0.

Marvin Bergeleen

Marvin,

This is not the definitive answer, but I have found that use of
WriteProfileString() surprisingly works for both NT and WfWG -
there is no need to play registry games.

While this can be used to set the default printer, unfortunately
it does not set printer properties like paper bins.

--
Les Schmalzbach
(remove nospam- to reply).

I searched the internet for "set default printer" and found VB code
using WriteProfileString() at
http://www.primenet.com/~simpson/printer2.html.  As you said, such
code can set the default printer (and the Control Panel | Printers
shows
it changed), but it does not set printer properties.  I then used
Printer.Orientation & .PaperSize, but they did not affect the Crystal
output.

I am now going to start  re-writing my routine which sets many
properties on the .OCX to use PrintEngine API calls instead.  I have
used some of the PE APIs before to display parts of report
definitions for our System Admin people to look at them.  This
does not look like fun.  :-(

Marvin Bergeleen

This is an update on setting the default printer.  I think I have
this
thing{*filter*}ed now, but then I have thought that before.

In the on-line, print-it-right-now version of the program, I was
letting the
user select the printer using the Crystal .OCX  .PrinterSelect
method.
I then added setting the default printer with the WriteProfileString
code.  The Landscape/Legal aspects of the report were wrong.

However, it turns out the problem was an interaction between
.PrinterSelect and setting the default printer.  Now I build a
listbox
from the Printers collection and let the user pick a printer from it.
I then set that as the default and run the report.  For the
combinations
I have tested so far, this has worked.

I have yet to try this in the version of the program which lets the
user pick the printer on-line but then the report runs later directly
on a server and goes to a printer.

Marvin Bergeleen