Report Sent to Printer? (4 Viewers)

[AHeyne]

In the real world, a contract is not legally binding until it has been signed by all parties and returned to the party that created the contract. Perhaps you should obtain proof the contract has been signed by all parties and then updating the status? Just because a contract has been printed does not mean the contract cannot be amended or cancelled.

Of course, Adobe Sign or Docusign could be integrated in a comprehensive manner.

 

[sonic8]

Use a timer to poll the status every 500 ticks (half second).You can set a limit of 10 seconds, (20 polls) using a loop. Play with the polling frequency and total time until you feel it's right.

I reply to this because that's the potential(!) flaw with your code suggested in #34.
My gut feeling (haven't had time to evaluate) is that half a second is too long an interval to reliably catch a document in the print queue of a PDF printer. At the same time half a second might be shorter than a remote print queue takes to respond to the query. So, this polling either might fail or completely block the application.
(While printing to PDF is not my primary concern at the moment, it is something I would like to have covered when creating a generic solution.)

In the real world, a contract is not legally binding until it has been signed by all parties and returned to the party that created the contract.

That's true of course. But printing the report creates a Schrödinger's contract from the application's point of view. It is a disconnected copy of the data that might be signed or might be shredded. The safe bet is to assume it is signed. If the contract needs to be cancelled of amended than users can do that in the application.

Perhaps you should obtain proof the contract has been signed by all parties and then updating the status?

This is a million times more likely to be forgotten by users than their instruction to not print from print preview, which already gets forgotten often enough for this task to have ended up on my todo list.

 

[RonPaii]

I know you rejected by previous suggestion to write the report to PDF and then present that to the user, but from the discussion I think that may be your best option. One of your issues with the PDF is that it is different from other reports, but this one is already different because you a requiring the user to remember never to print from preview. If you change the process to a complete and export action, the recording of the action becomes simple. It also supplies the user with the option to see the contract as it was when completed. Also if you want to further lock down the PDF, Windows folders can be configured to be write only.

I use this process for both purchase order and invoicing reports. All purchase orders are emailed, when generated an export tag is added to the data and end of report that can be referenced to set the PO Receive by vendor, Acknowledged, Approved flags.

 

[The_Doc_Man]

I'm with RonPaii on the idea that this is ALSO an employee education problem. The tech solution to after-the-fact capture the act of printing starts to require you to "split hairs" over how the file was prepared and how quickly your queue sampling code got to it. Instead of hoping and praying you can catch a transitory event, consider providing a command button that "officially" commits the report to a printer and (behind the scenes) also marks that action in order to lock in the changes. Then perhaps lock in the form that opens the report so that it always and only opens the report in a non-printing mode.

I.e. make the whole decision to "lock and commit" really easy to do by building in the feature. Don't TELL them what to do. GUIDE them through doing it the right way.