PDA

View Full Version : Solved: kill the printer



Dave
11-16-2007, 12:11 AM
Can you Word VBA a document so it can't be printed? Dave

lucas
11-16-2007, 07:55 AM
I think there is ultimately no way to keep someone from printing a word document if they really want to. How would you stop them from copying and pasting to a new word document and then printing that?

fumei
11-16-2007, 08:08 AM
I agree with Steve. There is no effective way to do this. There are ways to sort of do this, by removing Print commands, and buttons. However, there is simply no way to secure a Word document. If someone can see it, they can get it.

Copying to a new document, and printing that (as Steve mentions).

Doing a PrintScreen, and printing that.

Sorry. Word documents are not secure.

Dave
11-16-2007, 09:21 AM
Thanks for your replies. I sort of suspected that this wouldn't be possible. As you suggested, my concern is for document security. I had a notion that I would package a Word file within an .exe to be used as a help file. The doc would only exist during the .exe operation... but if it can be printed the .exe paper manual is worthless. Maybe I'll come up with a new plan? Dave

fumei
11-16-2007, 01:11 PM
Packaged within an .exe? How would that be possible? I can see an .exe calling a Word file, but "within"?????

"The doc would only exist during the .exe operation" Huh? By actually writing it? Again, I can see how an .exe could call a document file, and only have it open/active during .exe operation. But the document file would have to exist. How could a doc only exist during an .exe operation?

Dave
11-17-2007, 01:51 AM
Just add it as a resource file to a VB6 project. Here's an eg. of an XLS file. I'm pretty sure that a doc file works just as well.
http://www.mrexcel.com/board2/viewtopic.php?t=236856&highlight=resource
My thoughts were.. the exe. would include a temporary suspension of a running XL app, return focus back to VB6 then install and open the doc help file. On doc close, VB6 would kill the doc file and return to the XL app. Sure would be nice to get rid of that printing thing if somehow you could VBA the resource doc to not print. Dave

TonyJollans
11-17-2007, 03:20 AM
What is the obsession with not printing - not particularly your obsession, Dave, but a general one?

In the modern world if people have something in their hands - physically or on computer - they can copy it. Period.

Train, and trust, your people. If you - or your company - don't train people, they won't do the job properly. If you - or your company - don't trust people, you've got bigger problems than stopping them printing.

</rant>

Dave
11-17-2007, 08:45 AM
Thanks Tony for your insights. I didn't think there would be any harm at least asking if this was possible. I think that we have resolved the fact that it ain't possible to use a doc in the secure way that I was dreaming of. I will speak to my people in my company (ie. me) and see about getting some proper training. :) Hope you have a nice day. Dave

TonyJollans
11-17-2007, 09:57 AM
I don't know much about it and if you're doing this on your own then I suspect it's out of reach but you could look at IRM (http://office.microsoft.com/en-us/ork2003/CH011480781033.aspx) - Microsoft are attempting to address what is a concern for many companies.

Tommy
11-18-2007, 09:04 AM
Hi Dave,:hi:

Why not save the doc as .rtf file and display it in an rtf control that you have complete control over? I mean since you seem to be talking VB6. (RITCHX32.OCX)

Couple more pennies on the pile :)

OTWarrior
11-19-2007, 01:33 AM
I have yet to play around with the code for printing, but couldn't you get the document to disable the copy function in word, and to disable the print screen key (if the button is pressed then cancel?). obviously these would be re-enabled on document close

just a thought.

Dave
11-20-2007, 12:21 PM
Thanks Tony, Tommy and OTWarrior for your input. Tony...the MS link was interesting but probably beyond my needs/means. Tommy your suggestion makes cents but I don't know how to implement it. OTWarrior I think that what you're suggesting is exactly what I was trying to accomplish...care to suggest some code? Dave
ps. Apologies for the delayed response. Had a bit of a crash over the past few days. Seems to be fixed now.

fionabolt
11-21-2007, 05:53 AM
Here's the code to intercept the user pressing either ctl+c or using to the toolbar to select edit copy. This code would need to be placed in ThisDocument of the template.

Sub EditCopy()


MsgBox "Copy actions are disabled for this document.", _
vbOKOnly, _
Left(ActiveDocument.AttachedTemplate, _
Len(ActiveDocument.AttachedTemplate) - 4)

End Sub

You can then do something similar to intercept all the Word cut functionality (since this will be stored in the clipboard too), and also to intercept the print function.

There is nothing you can do to prevent users taking a screen shot tho.

I'm curious - what's so scary about users printing a help file?

fumei
11-22-2007, 11:08 AM
"There is nothing you can do to prevent users taking a screen shot tho."

Not strictly true. Try googling "Disable PrintScreen".

Dave
12-04-2007, 12:52 AM
Gerry...messing with the print screen button seems somewhat extreme... also the doc is some 50 pages, so that's alot of print screenin. So I guess I'm not that concerned. TOMMY... its actually the RICHTX32.OCX. I learned abit of stuff but I'm along ways from implementing your suggestion. Maybe a stupid question but ... Were you suggesting that I add this to a VB6 project as a control? I think I'm just going to stick with fancying up a doc. along with controlling the flow between the VB6, XL and Word appplications.
fionabolt... I'm at a loss to explain how your code works ... Word really is a mystery to me. It works great! This is the cut code as I recall (ie. this version untested). Same code with only a change in the name of the sub difference... too easy.

Sub EditCut()
MsgBox "Cut actions are disabled for this document.", _
vbOKOnly, _
Left(ActiveDocument.AttachedTemplate, _
Len(ActiveDocument.AttachedTemplate) - 4)
End Sub


The document is read only, so I believe that takes care of the Save options. Now to kill that damn printer option... and what about that sendto option? Not sure if it's a problem. Of course I tried the apparently magic code with the beforeprint, print commands, etc... didn't work for me. Thanks all for your help. My continued regrets for the delayed response.. perhaps my new VISTA will speed thing up :rotlaugh: Dave

Tommy
12-04-2007, 02:25 PM
TOMMY... its actually the RICHTX32.OCX. I learned abit of stuff but I'm along ways from implementing your suggestion. Maybe a stupid question but ... Were you suggesting that I add this to a VB6 project as a control? I think I'm just going to stick with fancying up a doc. along with controlling the flow between the VB6, XL and Word appplications.
My bad, fat fingers. Yes.

On the printscreen, onkey press check to see if the printscreen has been pressed and copy a empty bitmap to the clipboard, teach them a thing or two about that there printscreen! :devil2: There is also a way to clear the clipboard if you check for the keypress. I would need to find the code if you want it.

You can disable the menus/toolbars on load of Word (if you are just showing the doc).



perhaps my new VISTA will speed thing up :rotlaugh: Dave
Ok that was funny.:rofl:

Dave
12-05-2007, 12:08 AM
Clearing the clipboard on printscreen keypress seems harmless enough. I'm not too sure about changing menus around though. I sure would like to try a bitmap with a 1 finger salute but the notion of nothingness is very appealing. A bit of keypress code seems like it would nicely resolve the printscreen issue. Perhaps just disabling/enabling the whole file menu (and the edit menu) would be the path of least resistance and use the least code to resolve the other issues. Thanks Tommy. Have a fine day. Dave

Dave
12-28-2007, 02:20 PM
I've made quite a bit of progress on this topic, so I thought I'd post my results thus far. As far as program flow goes, passing control back to the VB6 program from the XL application (being run by the VB6 program) and then installing and displaying the help doc from the VB6 works but becomes very unstable and crashes on repetitive use. So I have decided to install the help file with VB6 before running the XL application. The help file is then opened by the XL application and all is well. When the XL application is quit, the help file is killed. So on the down side, the help file is actually available to copy during the period of the XL application operation. Not perfect but adequate for less sophisticated users. As for fancying up the help doc itself to avoid cut/copy/print etc. actions, the following code seems to pretty much do it.
..place code in ThisDocument code

Sub EditCut()
'disables all "Cut" ie. menu, mouse
MsgBox "Cut actions are disabled for this document.", _
vbOKOnly, _
Left(ActiveDocument.AttachedTemplate, _
Len(ActiveDocument.AttachedTemplate) - 4)
End Sub

Sub EditCopy()
'disables all "Copy" ie. menu, mouse, Control + "C"
MsgBox "Copy actions are disabled for this document.", _
vbOKOnly, _
Left(ActiveDocument.AttachedTemplate, _
Len(ActiveDocument.AttachedTemplate) - 4)
End Sub

Private Sub Document_Close()
Call StartMenu
End Sub

Private Sub Document_Open()
Call StopMenu
End Sub

Sub StopMenu()
'disable file menu, edit menu, and standard toolbar
Dim cbf As CommandBar, cbe As CommandBar, cbs As CommandBar
Set cbf = Application.CommandBars("file")
cbf.Enabled = False
Set cbe = Application.CommandBars("edit")
cbe.Enabled = False
Set cbs = Application.CommandBars("standard")
cbs.Enabled = False
'disable control + "P" (print)
FindKey(KeyCode:=BuildKeyCode(wdKeyControl, 80)).Disable
End Sub

Sub StartMenu()
'enable file menu, edit menu, and standard toolbar
Dim cbf As CommandBar, cbe As CommandBar, cbs As CommandBar
Set cbf = Application.CommandBars("file")
cbf.Enabled = True
Set cbe = Application.CommandBars("edit")
cbe.Enabled = True
Set cbs = Application.CommandBars("standard")
cbs.Enabled = True
'enable control + "P" (print)
CustomizationContext = NormalTemplate
KeyBindings.Add KeyCode:=BuildKeyCode(Arg1:=wdKeyControl, _
Arg2:=wdKeyP), KeyCategory:=wdKeyCategoryCommand, _
Command:="FilePrint"
End Sub


Now as far as the print screen thing, it seems that this could be addressed in a similiar way as the Control + "P" above. However, Word doesn't seem to have a name for this command. I haven't tried disabling the Control + PrintScreen as I don't know how to reset it without the command name so I'm not sure if it can be disabled. The following code should give the command name but produces only a blank messagebox.
Any further suggestions welcomed. Dave
MsgBox FindKey(BuildKeyCode(Arg1:=wdKeyControl, Arg2:=vbKeyPrint)).Command

fumei
12-28-2007, 02:56 PM
I gotta know the answer to the question fionabolt asked...

"I'm curious - what's so scary about users printing a help file?"

Seems like an extraordinary amount of work involved...for what again?

As for Tony's IRM suggestion...yeah, well...it only works if you are using 2003 servers. That is why we did not go to Office 2003 (well we are - some of us - using Outlook 2003, but all other apps are 2002). The really useful functionalities of 2003 (IMHO) do not truly come into their own unless you are using the full capacity of SharePoint Portals. Which we are not. It would have cost us $10,000,000 in license fees to Microsoft to go Office 2003 (from our existing 2002) ...and for what?

Hell, we can not even afford to XP our machines (90% still on Windows 2000), as we do not have licenses. 25,000 licenses is a lot of dough. Since we have already been sued by Redmond once before (to the tune of $440 million)...can you say "careful"? Problem of course is that Microsoft will no longer fully support Windows 2000.

Ooooops....a Gerry rant again. My apologies.

Dave
12-28-2007, 03:45 PM
Gerry I think that I addressed this above...

The doc would only exist during the .exe operation... but if it can be printed the .exe paper manual is worthless. Not really that much work/code. A nice glossy manual provided to only those that actually purchase the software may encourage folks to actually purchase the software rather than bootlegging it. Nice rant...who's Redmond? Any thoughts on that print screen thing above? Dave

fumei
12-30-2007, 02:46 AM
The guy asks "who's Redmond"? Are you serious? Just in case you are...Microsoft is headquartered in Redmond, WA. We got sued for $440 million and they won.

"A nice glossy manual provided to only those that actually purchase the software may encourage folks to actually purchase the software rather than bootlegging it" Nice thought. Good luck with that.

"Now as far as the print screen thing, it seems that this could be addressed in a similiar way as the Control + "P" above. However, Word doesn't seem to have a name for this command."

That is because PrintScreen is not a Word operation. It is a system OS level - actually...deeper than that - operation. It stems back to the old days. PrintScreen is basically..well, fully.. simply a dump of the video buffer. Its purpose was to be able to get a dump that would bypass ANY OS crash. In the old days there were plenty of those. But PrintScreen did nothing with the OS. It was, and is, independent. It is simply, and only, a dump of all the bits in the video buffer.

Now at...hmmm, I think Win2000, Microsoft brought in HAL. Essentially it was an effort (mostly sucessful, but not totally...like most Microsoft stuff) to disallow anything talking/communicating with hardware except through the OS. PrintScreen was one of the few remaining exceptions. It still does what it always did. Dumps the bits from the video buffer.

However, it can be disabled/redirected.

I would like to see clear code on replacing the dump bits with a empty bit buffer. That sounds deliciously annoying to people trying to bypass things using PrintScreen. There are API functions that disable PrintScreen. Again, google it.

Dave
12-31-2007, 10:26 AM
Thanks Gerry for the info on print screen. It is much appreciated. I also now know where to send my snail hate mail when my f'n Window breaks down again and makes me purchase "improved" software. I wasn't able to find any Google code that works with Vista... lots of gamer stuff that uses the print screen (argh). I think that I will abandon this part of the endeavor and mark this thread as solved. My learning thus far will do for my needs. As a farmer, I would much rather look at a nice glossy manual in its' entirety than print screen snippets anyways. Hope you have a great New Year! Dave :hi:
ps. here's a link I googled which is oddly enough a Vbax link... whoops
http://www.vbaexpress.com/forum/showthread.php?t=793&highlight=fileprint