PrintDialog problem

  • Thread starter Thread starter Mark Waser
  • Start date Start date
M

Mark Waser

Summary: dlgPrint.PrinterSettings.Copies always returns 1 regardless of
what the user entered

Details: When trying to print a document, I am first presenting the user
with the standard PrintDialog which was declared as "dim dlgPrint as new
PrintDialog()" After it is declared but before it is shown, a few
properties are set to some defaults including "dlgPrint.AllowSomePages =
true" "dlgPrint.AllowPrintToFile = false" and "dlgPrint.showNetwork = false"
Also, the dlgPrint.document property is set to a new instance of a
PrintDocument. To invoke the dialog, I am making a standard
"dlgPrint.showDialog()" call. If the return value is DialogResult.OK then
various fields are being used successfully such as
"dlgPrint.PrinterSettings.FromPage" and "dlgPrint.PrinterSettings.ToPage".
However, trying to see how many copies the user requested by checking
"dlgPrint.PrinterSettings.Copies" will always return a value of 1, whether
they have entered a 1 or a 5 or whatever.

Question: Is this a known bug? Is there any fix or workaround? - -
OR - - Is there any code which successfully does this that I can
use/modify?

I've tried looking at Google Groups, etc. and see some minor mention of a
problem like this but couldn't find the standard official acknowledgement.

Thanks.
 
Hi Mark,

Thanks for posting in the community.

According to MSDN, the PRINTDLG structure does not always contain the
correct value in its nCopies member. In some circumstances, the DEVMODE
structure will instead contain the right number of copies requested. It
depends on whether the application or the printer driver is responsible for
producing multiple copies.

From the MSDN:
"PRINTDLG.nCopies
Contains the initial number of copies for the Copies edit control if
hDevMode is NULL; otherwise, the dmCopies member of the DEVMODE structure
contains the initial value. When PrintDlg returns, nCopies contains the
actual number of copies to print. This value depends on whether the
application or the printer driver is responsible for printing multiple
copies. If the PD_USEDEVMODECOPIESANDCOLLATE flag is set in the Flags
member, nCopies is always 1 on return, and the printer driver is
responsible for printing multiple copies. If the flag is not set, the
application is responsible for printing the number of copies specified by
nCopies. For more information, see the description of the
PD_USEDEVMODECOPIESANDCOLLATE flag.

PD_USEDEVMODECOPIESANDCOLLATE
This flag indicates whether your application supports multiple copies and
collation. Set this flag on input to indicate that your application does
not support multiple copies and collation. In this case, the nCopies member
of the PRINTDLG structure always returns 1, and PD_COLLATE is never set in
the Flags member.
If this flag is not set, the application is responsible for printing and
collating multiple copies. In this case, the nCopies member of the PRINTDLG
structure indicates the number of copies the user wants to print, and the
PD_COLLATE flag in the Flags member indicates whether the user wants
collation."

Question: Is this a known bug? Is there any fix or workaround?
Click to expand...
Yes, we do have a known bug on this, but unfortunately, it would be punted
to Longhorn Beta 1.
We are sorry for the unconvenience.

However, the workaround may be using the DEVMODE.dmCopies value if
available, otherwise to use the PRINTDLG.nCopies value.
Another possible method might be to use whichever of DEVMODE.dmCopies or
PRINTDLG.nCopies is larger - but you need to make sure that one or the
other never contain spurious >1 values.


Wish it helps!

Best regards,

Gary Chang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
 
Mark,
The number of copies bug was in framework 1.0 and has been corrected in
framework 1.1. My code built against 1.1 will correctly print multiple
copies if the user selects that option.
AFAIK there was no fix for this in framework v1.0.

Ron Allen
 
Back
Top