Solved Report Sent to Printer?

[BlueSpruce]

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

Myabe so, but it would certainly prevent users from bypassing your app.

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.

It's post #54, not #51.

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

The locale provides me an understanding of their Laws, business practices, and user psychology.
Well, I have run out of suggestions. Best wishes for resolving how to handle this.

 

[Imb]

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.

I use the above idea to "view" a report, if it is in its final stage.

Left you see a column "Controles", with 7 checks.
When not ALL checks have succesfully passed (backcolor is green), the report on the right will show the red text.

In your case you could use the pressing of the Print button as "checks complete".

 

[The_Doc_Man]

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

So the question is, would they be there because they wanted to keep on doing something in a way that prevents you from fully meeting the business requirement? The question is, who posed this problem to you? Because at this point, you have some reliable solutions but the users won't like it. Or you have a back-breaking complex solutions so that folks can be allowed to continue giving you trouble.

I'd present this to the boss and let HIM decide (or HER - I'm not sexist). Then if you have to maintain the solution that causes you trouble, you at least know where you stand in the pecking order. But MAYBE the boss will send out a somewhat more official memo to your users telling them to straighten up their act because it is important to the business.

 

[sonic8]

@The_Doc_Man , in general I very much agree with your opinion and the proposed course of action.
In current context of this thread however, I disagree as follows....

So the question is, would they be there because they wanted to keep on doing something in a way that prevents you from fully meeting the business requirement?

They would be upset because globally disabling a standard keyboard shortcut for all applications (as @BlueSpruce suggested) is a very disproportional response to the problem discussed here.

Because at this point, you have some reliable solutions but the users won't like it. Or you have a back-breaking complex solutions so that folks can be allowed to continue giving you trouble.

This misses the current state we reached in this thread.
I got my API based solution, which the users would like very much if they knew about it.
In fact, they will not even notice the solution because they can carry on as they did before, only that now the application will work as intended.
If for whatever reason my approach fails in the production environment, I can fall back on the much simpler "preview with DRAFT watermark"-solution, which the users will not like as much but will very likely accept as a necessity.

Agreed, my API solution is hellishly complex inside but this complexity is encapsulated in a class. It should be treated as a black box, like a component from an external library. The code to integrate this solution is very minimal and unobtrusive.
To use my component, you would just add the following few (5!) lines of code:

---- In a form class module ----

Private WithEvents ContractPrintMonitor as PrintMonitor

Private Sub btnOpenPreview_Click()

    ' ... open report in preview
    Set ContractPrintMonitor = New PrintMonitor 
    Set ContractPrintMonitor.MonitoredReport = Reports("JustOpenedReport")

End Sub

Private Sub ContractPrintMonitor_ReportWasPrinted()
    ' Do whatever needs to be done when the report was printed
End Sub

The integration will be more complex if the report is opened as dialog because my PrintMonitor needs to be declared in the form but the assignment of the report needs to happen in the report_open event.

So, with the two solutions at hand now, there is no need to get upper management involved to tell the users to straighten their act.

 

[arnelgp]

the code came from Ai.
first the printer must be set (default) to a real printer (not pdf).
you open the Report in Report View and there is a "little" button
that user can click if he want to Print or Save to PDF.

Open ReportDemo1 in Report View.