Prevent certain reports from being printed

[chuckcoleman]

Hi, I have a report that I want to find a relatively easy way to make sure it can't be printed. A form opens the report in Print Preview mode which is what I want. However I want to make sure that it can't be printed. As I see it, there are three ways a user could print something; using the Quick Access menu at the top left, using Ctrl-P and also the Print button on the ribbon. I've done research but I can't find an example to prevent this. There is a simple DoCmd. command to hide the ribbon when the report is opened, but it doesn't prevent the use of Ctrl-P or the Quick Access menu. Any ideas?

Chuck

 

[theDBguy]

Let's say you managed to prevent printing from Access, are not concerned if the user can take a screenshot and then print that?

 

[chuckcoleman]

Hi DBG. I am aware that that is a possibility. I have a process going on in the background that captures is an invoice was viewed, printed or emailed. What I'm trying to do is make sure that the user doesn't view and use the Print Preview screen to also print it. Many things you can find a work around for. I just want to capture accurate information and if the user viewed the report and then printed it from the print preview screen, I wouldn't know that.

However, that just caused me to think I put code in one of the sections that lets appends the same data to a table that I'm using to see if they viewed it. Hmmn.

 

[theDBguy]

Wait, are you saying now that it's actually okay for them to print the report as long as you can tell that they did it?

 

[chuckcoleman]

Yes, I just need to track what they did.

 

[theDBguy]

Yes, I just need to track what they did.

By "Quick Access," do you mean the right-click menu?

 

[chuckcoleman]

No, Quick Access is the small menu of icons in the top left that a user can decide what icons they want "quick access" to. Like, Print, Save, Open, etc.

 

[theDBguy]

No, Quick Access is the small menu of icons in the top left that a user can decide what icons they want "quick access" to. Like, Print, Save, Open, etc.

Did you already disabled the right-click menu? I guess there are at least four ways the user can print the report.

1. Ctrl+P
2. Ribbon
3. Quick Access
4. Right-click menu

 

[sonic8]

I think, in theory it would be more efficient to detect whether the report is actually about to be printed and then prevent/cancel the printing process.
Unfortunately, I do not know any way to distinguish between print-preview and actual printing.
Maybe someone else knows how to do this?

 

[chuckcoleman]

Hi sonic8. I added code to the On Print section of the report that appends data to the table where I am keeping track of what's going on. Unfortunately, the On Print is activated when the report is Previewed. I am looking for a trigger when the report is sent to the printer vs. just viewed in Print Preview.

 

[The_Doc_Man]

Unfortunately, since Windows is involved in some of these options, it might not be possible to completely intercept all possible pathways unless you got involved in some of the Windows "policy" settings. I'm not aware of all of the policies so I don't know exactly what you can do, but local group policies can restrict certain actions. I'm not sure, though, that Access could control the policies - in fact, I strongly doubt that it can be done from Access at all.

Here is where you could look at editable local-group policies to see if there is even a chance of blocking unwanted actions.

Group Policy Editor Guide: Access Options and How to Use

Group Policy Editor (gpedit) is an important part of the Active Directory system administrator’s toolkit. Read this blog for more details about gpedit.

www.varonis.com

I would give you a more well-defined answer but unfortunately, Microsoft has not chosen to make Access an Open Source product. We cannot see how to modify or selectively interact with things like print triggering. Therefore, we are often in the dark regarding many options.

 

[LarryE]

Hi, I have a report that I want to find a relatively easy way to make sure it can't be printed. A form opens the report in Print Preview mode which is what I want. However I want to make sure that it can't be printed. As I see it, there are three ways a user could print something; using the Quick Access menu at the top left, using Ctrl-P and also the Print button on the ribbon. I've done research but I can't find an example to prevent this. There is a simple DoCmd. command to hide the ribbon when the report is opened, but it doesn't prevent the use of Ctrl-P or the Quick Access menu. Any ideas?

Chuck

Interesting question. I found this thread and maybe it can help you or others:
Where do I put Access vba code to only fire when physically printing? - Stack Overflow
I think you are going to have to capture the windows print action and then cancel it somehow.

 

[The_Doc_Man]

Interesting question. I found this thread and maybe it can help you or others:
Where do I put Access vba code to only fire when physically printing? - Stack Overflow
I think you are going to have to capture the windows print action and then cancel it somehow.

First, LarryE, I think you are quite correct about capturing the action and canceling it. But...

Second, IF this occurs in a domain-based environment (as opposed to a stand-alone tower or desktop on an isolated network circuit), cross-task permissions and privileges might get in the way. Printing is a Windows-involved operation that sends a print request to a Windows module that is out of the range of control of Access. In a standalone system, you frequently ARE the admin so it is not a biggie. But if it is a more secured environment, you might have to be VERY fast to catch the operation before the file makes it into the queue, because in a domain environment, the print queue isn't owned by the person who request the print action. And that means that Windows privileges for cross-task operations come into play. They are not very forgiving.

 

[chuckcoleman]

First, LarryE, I think you are quite correct about capturing the action and canceling it. But...

Second, IF this occurs in a domain-based environment (as opposed to a stand-alone tower or desktop on an isolated network circuit), cross-task permissions and privileges might get in the way. Printing is a Windows-involved operation that sends a print request to a Windows module that is out of the range of control of Access. In a standalone system, you frequently ARE the admin so it is not a biggie. But if it is a more secured environment, you might have to be VERY fast to catch the operation before the file makes it into the queue, because in a domain environment, the print queue isn't owned by the person who request the print action. And that means that Windows privileges for cross-task operations come into play. They are not very forgiving.

Thank you LarryE & The Doc Man. I'll explore this later today, I'm trying to figure out another issue now and I don't want to lose my train of thought. I do appreciate your help.

 

[LarryE]

First, LarryE, I think you are quite correct about capturing the action and canceling it. But...

Second, IF this occurs in a domain-based environment (as opposed to a stand-alone tower or desktop on an isolated network circuit), cross-task permissions and privileges might get in the way. Printing is a Windows-involved operation that sends a print request to a Windows module that is out of the range of control of Access. In a standalone system, you frequently ARE the admin so it is not a biggie. But if it is a more secured environment, you might have to be VERY fast to catch the operation before the file makes it into the queue, because in a domain environment, the print queue isn't owned by the person who request the print action. And that means that Windows privileges for cross-task operations come into play. They are not very forgiving.

I was quite sure there might be lots and lots of "buts". I just ran across the thread and thought maybe it might help. I have not a clue how to implement, but I guess you would call the procedure somehow. But then what about other reports that you do want to print?

All this is waaaaay out of my knowledge base....

 

[sonic8]

But if it is a more secured environment, you might have to be VERY fast to catch the operation before the file makes it into the queue, because in a domain environment, the print queue isn't owned by the person who request the print action.

Unless my memory fails me, the print queue itself is always owned by the operating system. Each print job (document) is owned by the Windows user account printing the document. This user can cancel any of their own print jobs as long as the printer has processed it.

 

[xavier.batlle]

Perhaps these videos by Richard Rost can help you: