>>>>>>>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.
>
>Yes, that has been my experience too, but in this case the business delivers parcels to their customers so the driver needs that piece of paper to give to the customer along with the package. It would be nice if they could sign electronically for the package but the business has not yet reached there yet and not all the customers have email addresses. They do actually email the customers who have provided email addresses the delivery charges before hand.

Had guessed that it was something of that nature. Even queue-querying would not be errorfree - only paper seen is enough.
Either go totally pragmatical and see if in their workflow are certain error patterns where you can make the fix easier or make the flag setting dependant on "produced paper", like printing a barcode and scanning that when putting paper and parcel together in truck. Minimize the cost of manual checking that report was done correctly via workflow and/or automatic readers or minimize workflow/cost impact of errors after the print is executed, including operator errors and stop worrying about getting one or two steps closer to the printing action, as even then not all error possibilities are taken care of...