Solved Report Sent to Printer? (2 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.

 

[BlueSpruce]

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

An online service that provides a work flow for distributing documents, signing, and return could be integrated via API's to automate the status update in your Access app. We have customers using Access/DotNet interop apps that fulfill those needs.

 

[sonic8]

An online service that provides a work flow for distributing documents, signing, and return could be integrated via API's to automate the status update in your Access app.

In theory it could.
In practice it makes very little sense because the customer supposed to sign the contract is physically there, in person, expecting to get a paper copy of the contract just signed.

 

[BlueSpruce]

In practice it makes very little sense because the customer supposed to sign the contract is physically there, in person, expecting to get a paper copy of the contract just signed.

If the customer is physically there to get a paper copy [receipt] of the contract just signed, then I think you're over complicating the need to know if they received the paper copy, when your app can just change the status of the contract to 'printed' so your users cannot edit the contract.

 

[tvanstiphout]

If detecting Preview > Print is difficult, one new idea is to not have a Preview button. Perhaps the DATA can be previewed (in some form / subforms, not trying to faithfully show what would be printed), but the only way to get a printout is to click the Print button, which then allows user to select the output destination, and it goes there, and the data can be marked as "cannot modify anymore".

 

[sonic8]

one new idea is to not have a Preview button.

I don't like this idea for reasons I will explain in the post after the next (#51).
But, this just gave me an idea that would have been a super simple solution...
I don't want to rob the users of the possibility to see the report in preview. However, I could show the user a preview but at the same time make this preview unsuitable for printing the final report. E.g., by putting a large "DRAFT" watermark in the background of the report when opened in preview. - This is not the perfect solution, but considering the extreme difficulty of detecting the print of the preview, it would be acceptable.

Luckily, I don't think I'm going to need this. But it will be my fallback if the current solution fails in the target environment.

 

[sonic8]

then I think you're over complicating the need to know if they received the paper copy, when your app can just change the status of the contract to 'printed' so your users cannot edit the contract.

I do not care whether the customer received their copy.
I can change the status to printed anytime. But when do I do that? You leave this question unanswered and this was the core question right from the start of this thread.

 

[sonic8]

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.

Well, the requirement to not print from preview was the status quo ante. The objective of this thread's underlying question was to get rid of this requirement.

and how quickly your queue sampling code got to it.

That was a problem with the polling of the printer queue suggested by others. Polling the queue is indeed problematic and for exactly this reason I rejected those suggestions. - My solution (outlined before and below) does not suffer from this problem.

Try the code below that uses Windows Management Instrumentation through the GetObject function to detect the status of remote print jobs.

This was that type of unverified AI output I asked not to post.
The QueueStatus property does not exist and the translation of numeric status to text does not make sense to me with any of the actually existing status properties one could get from the WMI printer object.
But the fatal problem of this approach is something else...

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.

The code you posted takes on average 850 ticks to run when querying the queue of a local printer already. I couldn't test it, but I'm convinced it will take longer for a remote print queue.
850 ticks is already much too long, to reliably catch a document in the queue of a PDF printer (which admittedly was/is not my primary concern).

I'm with RonPaii on the idea that this is ALSO an employee education problem.

I find it hard already to justify to educate users to not use an innocent keyboard shortcut like [CTRL]+[P]. - I personally hate it, when applications do not support generic standard shortcuts of the OS.

The idea to "guide" users by taking away well-known sensible features/functionality because the application cannot cope with them is a an absolute last resort to me. I strongly dislike the idea to make user's lives harder or more uncomfortable to make my work easier. This often is an easy approach to solve problems such as this one, but it is also a declaration of UX design bankruptcy by the developer.
Of course, pouring this amount of effort into this problem is highly questionable from an economic point of view. My client would have never approved this in advance and would be extremely upset if I would charge them for this in full without prior approval. - I won't.

I'm going to mark this thread as resolved now.
I pieced together all my individual proof-of-concept code snippets based on the Printer Change Notification Functions API.
My solution sketched:
When the report is opened in preview, I create a change notification object using FindFirstPrinterChangeNotification monitoring the print spooler of the report's printer for new jobs being added to the queue.
Luckily I discovered the RegisterWaitForSingleObject function, which allows to wait for an Windows event (signal) and then have the OS create a new thread invoking a callback function in my VBA code.
Unfortunately, the FindNextPrinterChangeNotification intended to retrieve additional information about the event behaves not entirely predictable. So I query the print spooler using the GetJob API to check whether the print job raising the event matches my report.
If yes, the report was printed.

My solution works reliably during runtime in my local environment. I will deploy this into the client's environment in the next couple of days and then will see if it also works reliably there.
I'm not sure yet if I will publish the source code for this. Certainly not before the client confirmed it working for them.

Of course, querying an external entity such as the print spooler to know if and when my report was printer is not the ideal solution. However, after my initial research and the discussions in this thread, I believe it is the only way this can be reliably achieved.

Thank you all for your valuable contributions to this thread and for all your suggestions.

 

[BlueSpruce]

I can change the status to printed anytime. But when do I do that? You leave this question unanswered and this was the core question right from the start of this thread.

You do that when users press the Print Contract button. You said the customers are on premise. So if for x or y reason they didn't get a copy of their contract, they will notify someone on premise and the contract can be reprinted on a different printer, or emailed to them? How often have customers not received a copy?

 

[sonic8]

How often have customers not received a copy?

I do not know and I do not care.
The problem is the other way round. Customers showed up with their genuine signed copy of the contract that according to the application was never printed out.
I can't say how often this happened but often enough for my client to present this as a problem to be resolved to me.

 

[BlueSpruce]

I do not know and I do not care

So then why bother trying to find out if the printer queue received the print job? Just set contract's print status as printed immediately after users press the print button and be done with it. That eliminates the scenario of customers showing up with printed contracts and your app not reflecting it as printed. You can also email a copy as a backup just in case ...

 

[BlueSpruce]

I find it hard already to justify to educate users to not use an innocent keyboard shortcut like [CTRL]+[P]. - I personally hate it, when applications do not support generic standard shortcuts of the OS.

You can disable Ctrl+P, Ctrl+C, and other OS level shortcuts in the Group Policy Editor (GPEDIT.EXE).

Is Ctrl+P the reason why customers have shown up with printed contracts despite your app not showing it as printed?

What locale and language is your app runing in?

 

[sonic8]

Just set contract's print status as printed immediately after users press the print button and be done with it

The user never pressed the print button.

 

[BlueSpruce]

The user never pressed the print button.

Disable Ctrl+P at the OS level in the group policy editor. See my post #55.

 

[AHeyne]

I don't want to rob the users of the possibility to see the report in preview. However, I could show the user a preview but at the same time make this preview unsuitable for printing the final report. E.g., by putting a large "DRAFT" watermark in the background of the report when opened in preview.

Looking back, I think this approach is actually pretty brilliant.
It's simple, understandable, and absolutely waterproof.
These criteria make it the best solution.

If I were you, I would implement it this way and throw the APIs overboard.

If I ever find myself in this situation, I hope I'll remember this.

 

[xavier.batlle]

This is my approach for previewing a report and not allowing to print it. I don't think it's 100% reliable, but it might be useful to someone.

 

[sonic8]

You can disable Ctrl+P, Ctrl+C, and other OS level shortcuts in the Group Policy Editor (GPEDIT.EXE).

If I'd do that, a mob of angry users would be at my doorstep with torches and pitchforks that very night.

Did you read #51? I would never do that even if I could. (I can't). The people who can would also never do it.

Is Ctrl+P the reason why customers have shown up with printed contracts despite your app not showing it as printed?

This is the most likely explanation.

What locale and language is your app runing in?

Why would that be relevant?
Most users use de-DE. I cannot be sure if this applies to all.