Hi jkopelman,
After completing a full investigation in response to your query, I can
say that it is possible to restrict the save, print, and delete
functions within the Office suite itself. The same cannot be
guaranteed if files are opened by other applications.
In the attempt to keep Office as open to customization as possible,
Microsoft has provided a specialized language called VBA, or Visual
Basic for Applications. This is the language used to write code for
use within the collection of Office applications (including Word and
Excel). This is actually a subset of the Visual Basic programming
language and follows the same syntactic rules.
Using VBA, a developer has significant capability to alter or enhance
the functionality included by default within Office. There is a full
collection of libraries, or APIs, that facilitate this. The major
organizational units that encapsulate code segments are called
'macros' and 'functions'. One level higher, macros and functions can
be placed in a 'Module' or 'Class' - these can reside in a file or
within the Office application through a template (so that it is
applied to every file opened within the program). In addition to
allowing for the creation of customized macros which can provide
something that Office may not be capable of doing immediately, it is
also possible to 'override' the built-in features (since they are
encapsulated by macros also).
An excellent walk-through of overriding built-in functions is
available from the following
http://word.mvps.org/FAQs/MacrosVBA/InterceptSavePrint.htm
Note that the above is just a sample of some of the "obvious"
functions that would need to be overriden. There are others, and so
additional analysis would need to eliminate any holes - though I have
attempted to provide a fairly comprehensive list. The point, though,
is that essentially anything you can do through a menu or shortcut key
can be customized. I have gone through the the set of Word commands
and tested that the following functions should be overriden as well to
prevent alternate ways of achieving the same basic means (this is for
saving, printing, and copying). Below is a list of built-in Word
functions that would need to be overriden:
DocClose - prompts to save the document and then closes the document
EditCopy - Copies the selection and puts it on the Clipboard
EditCopyAsPicture - Copies the selection and puts it on the Clipboard as a picture
EditCut - Cuts the selection and puts it on the Clipboard
FilePrint - Prints the active document (brings up dialog window first)
FilePrintDefault - Prints the active document using the current
defaults (no dialog window)
FilePrintPreview - Displays full pages as they will be printed
FilePrintPreviewFullScreen - Toggles full screen
FilePrintSetup - Changes the printer and the printing options
FileSave - Saves the active document or template
FileSaveAll - Saves all open files, macros, and AutoText entries,
prompting for each one separately
FileSaveAs - Saves a copy of the document in a separate file
FileSaveAsWebPage - Saves a copy of the document in a separate file
FileSaveFrameAs - Saves a copy of the current frame document in a separate file
FileSaveHtml - Save file as HTML document
FileSaveVersion - Saves a new version of a document
MoveText - Moves the selection to a specified location (drag and drop)
In addition to these, there are some important macros (not listed in
the list of Word commands) that are used to insert actions upon the
starting of the Office application, opening a file, and closing a
file. These are called event-based macros. A further discussion of
this is available from:
http://word.mvps.org/FAQs/MacrosVBA/DocumentEvents.htm
Now that we have identified some set of functionality that we would
like to alter, the next step is to determine how to have this
installed on a user's machine. THe answer to this is to use what is
called an Add-In. The user will knowingly install this add-in, which
is accessible through the 'Tools > Templates and Add-Ins' option in
case they need to remove it in the future. Since we need to be able to
install the add-in, it will be necessary to create a COM component.
Microsoft has published a detailed guide of how to do this using
several programming languages:
Visual C#.NET (C-Sharp)
http://support.microsoft.com/default.aspx?scid=kb;en-us;302901
Visual Basic.NET
http://support.microsoft.com/kb/302896
Visual Basic 6.0
http://support.microsoft.com/kb/238228
Visual C++
http://support.microsoft.com/kb/230689
At a high level, using any of the solutions outlined in the above
links will yield an add-in which can be installed directly into an
existing Office installation.
From what I gathered regarding your ultimate intention with the final
product, I have outlined a basic architectural description some of the
major functional areas that would make sense to include in the add-in.
To keep the terminology simple, let's call "publishing" the process of
protecting a document from the actions you've stated.
1. Publishing a document
This is the process of taking an existing document and applying
functional changes to the document. In order to achieve this, the
add-in will need to place the pre-developed override and event macros
into the specific document. This will ensure that when a document is
opened elsewhere, it takes with it the desired functional alterations.
In addition, some sort of 'watermark' should be embedded in the
document. This can be done in a number of ways - an example would be
to set a non-visible property within the document.
2. Opening a published document
When a previously published document is opened on a machine that also
has the add-in installed, the add-in will recognize the 'watermark'
and open the document according to the overriden functionality defined
by the add-in. This will be done by the event macro run each time a
document is opened. Recognition of a published document can kick off
numerous other code-based customizations (you can determine the
specifics). Some suggestions would be 'graying out' toolbar options,
restricting certain keystroke combinations, etc. The possibilities
here are endless, and should only be applied to actual published
documents. You could even generate a encrypted password, so that a
published document cannot be opened unless the application includes
the add-in.
These are code-specific features - just thought you may value some suggestions :)
Comments:
The above description is a very simple implementation which can be
extended to give the publisher far more power. This may include
providing an interface for the originator of the document to specify
exactly what features they may want to be made available.
Restrictions/Challenges:
As alluded to by the comment by crashridedrummer-ga, this system is
not foolproof. A determined user can access at least some of the
content of a published document in ways that you are trying to
restrict. For example, you can try to open a Word document in a plain
text editor. Although any formatting is lost, you can usually recover
a fair amount of plain text data. This is the risk of working within
an operating system that has made provisions to allow files to be
accessed by any myriad of applications. You may also want to consider
how users of alternative Office-compatible suites sun as Sun
Microsystems' OpenOffice (http://www.openoffice.org/) may impact your
business model.
I wish you all the best in your business endeavour - if you have any
problems understanding the information above, please request a
clarification and I'll be happy to get back to you.
If you have follow-up questions that go beyond the scope of your
original question, you are welcome to direct additional questions
directed to me (answerguru-ga). Your question has really got me
thinking!
All the best to you and yours this holiday season :)
Cheers!
answerguru-ga |
