1

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!

Jordan
  • 9,014
  • 8
  • 37
  • 47

1 Answers1

1

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.

Adrian McCarthy
  • 45,555
  • 16
  • 123
  • 175
  • Your description of the mechanics is correct. The problem is that this is all supposed to be handled by MFC's View framework. Your code shouldn't ever need to put up the Print dialog, much less deal with the DEVMODE that it returns. – Mark Ransom Dec 05 '11 at 22:24
  • So, is it just something in my codebase that's breaking it then? I'll admit that it's a high possibility, but I literally just call CView::OnFilePrint(). Or can I somehow just get the data from the dialog and then print silently without bringing up the dialog again? – Jordan Dec 05 '11 at 22:26
  • @Mark Ransom: Ah, I see. I've never used MFC, but I've done a lot of Win32 printing. Could be a buggy driver then. I wonder if Jordan has tried it on multiple printers. – Adrian McCarthy Dec 06 '11 at 17:49
  • Yeah, it was indeed the devmode. I just created my own print dialog with that flag. Thanks! – Jordan Dec 16 '11 at 19:22