How to detect actual number of print copies sent from MSWord

Hi! Am going nuts trying to determine how many print job copies has a user
selected from the print dialog in Microsoft Word. I'm writing a program that
monitors all print jobs and reports information (no. of pages, no. of
copies, etc.) to a server. It works perfectly with the printer and print job
API, getting the info from the DEVMODE structure (dmCopies, etc.), with any
application except for: guess what... Microsoft Word and Microsoft Excel.
Microsoft Excel reports n separate print jobs for a print job with n copies,
which is quite unique, no other app does this, and of course it spoils the
functionality of my program, but not in a fatal way.
Microsoft Word reports a single copy no matter how many the user is actually
printing, I couldn't find any way it actually tells the printer how many
copies does it want, and this of course completely ruins the functionality
of my program.
If anyone out there has encountered this abnormal functionality of these
applications and knows any way around this, please help.
Or maybe someone can at least explain to me why in the world all the
applications ever written comply to the Microsoft Printer API, except for
these two Microsoft Applications.

Thanks a lot,
Claudiu.

If the printer is capable of collating the output, then WORD could deliver a
single print job with the copies and collation fields set in DEVMODE. The
printer would either print the whole job dmCopies times, or print each page
dmCopies times, depending on dmCollate. Otherwise, if the user hasn't
requested collating, WORD could send the print job multiple times requesting
one copy each time (as for Excel). But if the printer driver doesn't
support collation and the user has requested it, then WORD has no option but
to duplicate pages (if more than one copy is selected) and send the whole
job to the printer as a single copy.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Claudiu Stoicescu" wrote in message
...
Hi! Am going nuts trying to determine how many print job copies has a user
selected from the print dialog in Microsoft Word. I'm writing a program
that
monitors all print jobs and reports information (no. of pages, no. of
copies, etc.) to a server. It works perfectly with the printer and print
job
API, getting the info from the DEVMODE structure (dmCopies, etc.), with
any
application except for: guess what... Microsoft Word and Microsoft Excel.
Microsoft Excel reports n separate print jobs for a print job with n
copies,
which is quite unique, no other app does this, and of course it spoils the
functionality of my program, but not in a fatal way.
Microsoft Word reports a single copy no matter how many the user is
actually
printing, I couldn't find any way it actually tells the printer how many
copies does it want, and this of course completely ruins the functionality
of my program.
If anyone out there has encountered this abnormal functionality of these
applications and knows any way around this, please help.
Or maybe someone can at least explain to me why in the world all the
applications ever written comply to the Microsoft Printer API, except for
these two Microsoft Applications.

Thanks a lot,
Claudiu.

Thank you for your reply, but unfortunately this is not the case.
Any other application except for Microsoft Word and Excel uses the dmCopies
and dmCollate fields of the print job's DEVMODE structure to store
information exactly as you described below.
And that is exactly what they should do, since the printer(s) I'm using all
support multiple copies and collation, and the print result is fine.
But Microsoft Word and Excel simply do not populate these two fields
(dmCopies and demCollate) of the DEVMODE structure, no matter what the user
selections were. They simply don't, yet somehow they manage to print the
appropriate number of copies. It's clear how in the case of Microsoft
Excell, which instead of populating the dmCopies field of a n copy print
job, actualy prints n separate print jobs. But in the case of Microsft Word,
it's a mistery how the printer driver knows how many copies to print, since
it only receives one print job, with no information in dmCopies, and the
exact number of pages (TotalPages) of one and only one copy (so no, Word is
not internally multiplying pages).
All these happen in 100% of cases, with absolutely no reason at all
determined by either the printer driver, printer hardware, user selections,
etc., as all possible combinations of these factors have also been tested
against a multitude of other applications, with correct results.
So, any idea why?

Thank you,
Claudiu.



"Jeff Richards" wrote in message
...
If the printer is capable of collating the output, then WORD could deliver
a
single print job with the copies and collation fields set in DEVMODE. The
printer would either print the whole job dmCopies times, or print each
page
dmCopies times, depending on dmCollate. Otherwise, if the user hasn't
requested collating, WORD could send the print job multiple times
requesting
one copy each time (as for Excel). But if the printer driver doesn't
support collation and the user has requested it, then WORD has no option
but
to duplicate pages (if more than one copy is selected) and send the whole
job to the printer as a single copy.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Claudiu Stoicescu" wrote in message
...
Hi! Am going nuts trying to determine how many print job copies has a
user
selected from the print dialog in Microsoft Word. I'm writing a program
that
monitors all print jobs and reports information (no. of pages, no. of
copies, etc.) to a server. It works perfectly with the printer and print
job
API, getting the info from the DEVMODE structure (dmCopies, etc.), with
any
application except for: guess what... Microsoft Word and Microsoft
Excel.
Microsoft Excel reports n separate print jobs for a print job with n
copies,
which is quite unique, no other app does this, and of course it spoils
the
functionality of my program, but not in a fatal way.
Microsoft Word reports a single copy no matter how many the user is
actually
printing, I couldn't find any way it actually tells the printer how many
copies does it want, and this of course completely ruins the
functionality
of my program.
If anyone out there has encountered this abnormal functionality of these
applications and knows any way around this, please help.
Or maybe someone can at least explain to me why in the world all the
applications ever written comply to the Microsoft Printer API, except
for
these two Microsoft Applications.

Thanks a lot,
Claudiu.

While the printer you happen to be using supports multiple copies and
collation in the print driver, not all do. An application that wants to
provide the feature in all cases must implement the procedure for this
internally. Note that you cannot tell from the print dialogue whether the
feature is supported at the application or driver level, except that if it's
not supported by the application _or_ the driver, the option won't appear.
Given that WORD supports it internally, it seems that they chose to
implement it for all devices. This is common practice where a device feature
is optional, because once you've coded for the complex case (ie the driver
does not provide the feature) then you can implement the same functionality
in the simple case with no extra effort. There's no rule that says you have
to use a driver feature if you don't want to, or if you've already
implemented it within the application.

The page multiplication is happening in the print data stream only and will
never be visible in page counts or file size. It happens in 100% of cases
because WORD is treating all printers as equivalent as far as this feature
is concerned.

Find a printer that you _know_ doesn't support multiple copies (a virtual
printer such as PDF might be a good choice). Select it as the printer for a
WORD document. You still get the number of copies option. For other
applications, some will, some won't.
--
Jeff Richards
MS MVP (Windows - Shell/User)
"Claudiu Stoicescu" wrote in message
...
Thank you for your reply, but unfortunately this is not the case.
Any other application except for Microsoft Word and Excel uses the
dmCopies
and dmCollate fields of the print job's DEVMODE structure to store
information exactly as you described below.
And that is exactly what they should do, since the printer(s) I'm using
all
support multiple copies and collation, and the print result is fine.
But Microsoft Word and Excel simply do not populate these two fields
(dmCopies and demCollate) of the DEVMODE structure, no matter what the
user
selections were. They simply don't, yet somehow they manage to print the
appropriate number of copies. It's clear how in the case of Microsoft
Excell, which instead of populating the dmCopies field of a n copy print
job, actualy prints n separate print jobs. But in the case of Microsft
Word,
it's a mistery how the printer driver knows how many copies to print,
since
it only receives one print job, with no information in dmCopies, and the
exact number of pages (TotalPages) of one and only one copy (so no, Word
is
not internally multiplying pages).
All these happen in 100% of cases, with absolutely no reason at all
determined by either the printer driver, printer hardware, user
selections,
etc., as all possible combinations of these factors have also been tested
against a multitude of other applications, with correct results.
So, any idea why?

I have the same problem with Word, and as far as I can tell there is
no way round it. If anyone has found a magic solution, please let me
know!

Cheers,
Bob.