Question

I have a class which derives from CView which calls OnFilePrint(), but it seems as though only one copy ever gets printed regardless of how many I enter in the print dialog. Is this a known bug, or am I doing something wrong?

I could potentially create my own CPrintDialog, but I'm not quite sure how to actually have it do the "printing" as it were. Something along the lines of the following?

CString PrinterName;
CString SelectedPrinter;
CPrintDialog dlg(FALSE);

int nCopies = 1;
if( IDOK != dlg.DoModal())
    return;
nCopies = dlg.GetCopies();

for(int i=0;i<nCopies;i++)
    //do something??

What am I missing? Also, if the user selects a pdf printer, how would I prevent the code from prompting the user for the file save location "nCopies" times?

Thanks for the help!

Was it helpful?

Solution

I would have expected that any modern version of Windows would handle the copies in the print processor and relieve the program of the burden (just as it does with banding printers). But your question suggests otherwise.

My memory is rusty, but, as I recall, some printers (or their drivers) will make copies, but others require the program to do it. The dialog captures the user's intent by setting the dmCopies field in the DEVMODE.

The program should then check with the driver to see if it supports multiple copies. If it does, just pass in the DEVMODE. If it doesn't, then you need a loop like the one you've shown (and you reset the DEVMODE dmCopies field to 1).

I forget how to ask the driver if it supports copies. Maybe it has to do with checking if the DM_COPIES bit is set in the dmFields of the default DEVMODE. I do remember that in the bad old 16-bit days, a lot of drivers claimed to support copies but didn't actually do it. The application I worked on at the time had a list of drivers that said they could do copies but couldn't.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top