Configuring a printer to do Duplex Printing

[Paul Ridings]

Hi

I've managed to configure my printer to print my report front and back
(duplex styl;e) by configuring the printer's INI file in design mode of the
report. My problem is that I would like to do this when the database is
compiled into an MDE, but the report forces an error when it tries to go
into design mode because you cant design a report when in an MDE.

Can anyone tell me a workaround for this or perhaps another way to configure
duplex printing on a report within an MDE.

Many thanks in advance.

Paul

 

[SA]

Paul:

A.) There's no such thing as a report's "INI" settings. If you mean the
prtDevMode property then you are correct you can't get to that in design
mode in an MDE.

B.) So to get to a solution, you need a short primer on what Access reports
store internally at design timeand how they interact with printer settings
at run time.

1.) The Devmode settings (where duplex printing is specified) for a report
are saved with the report. If you set a report to use a specific printer
and set the printer's properties when the report is in design mode to print
in duplex fashion and then save the report, that setting is stored in the
report itself. If you then set the report to print to the default printer
(which is always recommended when distributing a database,) the duplex
setting will remain as a saved value in the report and will be applied until
and unless the report is previewed and the user switches to a different
printer or has a default printer (that may or may not support duplex
printing,) where the default duplex property is set to off or none, in which
case the report will revert to non-duplex setting.

Any time a report is changed (normally in preview) to use a different
printer, Access "adopts" for the report at run time, the selected printer's
default layout, paper size, duplex and other settings when the new printer
is selected in preview mode. This will impact landscape layouts and other
report properties such as duplex printing as well causing them to be
overridden even when saved in a report in an mde for that particular run.
(Close the report and reopen it to a default printer that supports duplexing
and it will still have the duplex setting applied; the issue is when the
switching of printers occurs).

2.) So to assure that your report remains in duplex mode in an mde, what you
have to do is to set the current default printer's default value for
duplexing to yes, before the report is previewed or printed. To make sure
that user doesn't switch printers during preview (which causes the report to
adopt the newly selected printer's default properties which are normally
non-duplex) you have to eliminate the option to print the report from
preview mode (i.e. by using custom toolbars and menus for your report that
eliminate the print option.)

From a design stand point, how you give the user printer options is that on
your form from which the report is printed or previewed, you provide the
user with a printer selection a combo box; when the user selects clicks the
print or preview button you app must then set then target printer's duplex
property to true to match the report's requirements before the report is
previewed or printed. This will make sure that the duplex setting is
applied when the report is previewed or printed because the db application
is controlling target printer's default properties making them match what
the report needs before the report is sent to the output device (either
screen or printer.)

To modify a printer's underling print default settings, you have to use api
calls. (Open printer, get printer and set printer.) This can be a pain to
work out. If you'd like a fairly ready made solution to this issue, you
might want to look at our "On the Fly Printing" classes, which includes a
PrintersClass whereby you can set a target printer's default layout, paper
size and tray; based on your understanding of the DevMode, it would be easy
to modify the the class to support setting the printer's default duplex
property to true as well. Everything else is worked out for you in terms of
applying the settings to the printer. You'll find OTF on our web.

HTH

 

[Paul]

Steve,

Thanks very much for the detailed reply. Your right, it is the prtDevMode,
my mistake. In my MDE, each user can select any of up to 10 printers off
the network and I use API's to set it as the default (The users very rarely
change printers). Only a few of these 10 printers support duplex printing.
The report is called from a button on a form and is never previewed (print
icons are not available, so previewing shouldnt be a problem).

To modify a printer's underling print default settings, you have to use api
calls. (Open printer, get printer and set printer.)

I'm using the open, get and set api calls already and they seem to work in
an MDB, but it was my understanding I could only use these settings when 'a
report' was open in design mode. Perhaps I'm mistaken. I'll have a look at
your site and see how far I get.

Thanks again for the info, didn't think I would get a reply

Paul

 

[Guest]

Steve,
Your discussion here interests me as I am having a related problem. I have made a previous post about my issue, but thought I'd at it here as you have answered half my question already.
Basically our client requirements include some reports of an Access project to be printed in duplex and/or on letterheads (from a specific tray of a specific printer).
As we are developing the project off-site, these settings obviously get set back to "default printing" every time we open a report for design or preview on our development machines. I have also tried to implement VSS for our Access projects, which makes the whole problem worse because VSS opens up every single report in the project as it builds the ADP file.
I am not sure if you know about VSS integration with Access 2000, but basically it stores all objects (reports, forms etc) as text files, so it is easy-ish to see the prtDev parameters as strings of hex-numbers.
Do you think it would be possible to use these strings and assign them to the appropriate prt parameters programatically when launching the reports?
If it would make it easier, I will be able to post an example of what these text files.
Hope I haven't made my description too complex, and hopefully you can share some usefull advice.

Thanks,

Michael