>>>>>Yup, using the winforms report viewer. What I want to do is after the user has hit the Print button in the dialog and the report sent to the spooler, prompt the user if the report printed properly and if so, then I'll update a table. For now, what I am doing is showing the reportviewer in a modal form and when it is closed I ask the user if it printed.
>>>>
>>>>I've never used the ReportViewer. Do you get access to the PrintDialog directly. If so is this the Winforms (System.Windows.Forms.PrintDialog) or the WPF (System.Windows.Controls.PrintDialog) version ?
>>>
>>>From what I can see I can trap when the user hits the Print button in the print dialog, not much else. How do I tell which version of the Print Dialog?
>>
>>you should not do that - opens code up to problems with each new OS iteration/addition.
>>Dunno if you were using batch print jobs with systems before the DOS era - if so, think along those lines.
>>Trap / query only the internal machinery (back then operators were part of the machinery), not the GUI.
>>Sounds like a different approach might be needed, as printers can fail:
>>pipe report into file/pdf, save piped report in DB - if print job failed/got destroyed, they can get another copy from the DB.
>>Or get a printer (some fax systems used to do that) that will generate a report after printing.
>>Still mechanical error (in old times bad printer ribbon) might make it neccessary to have the saved fall-back report.
>>
>>Just a quesy feeling that you are not using the fitting weapons for the problem at hand.
>
>I feel pretty queasy too :(

I agree with Thomas' idea of going to an intermediate file. I would go a step further and ask your client if they would prefer to go paperless - fire a PDF to peoples' inboxes. Once you point out it's faster, more reliable and costs less it's often an easy sell, you just have to get past the "that's the way it's always been" mindset.