Win32 Hooks
-
I'm trying to write my own save dialog (to replace the one in word 2003) but I'm unsure of how to go about it. I haven't found very much information about this topic on the internet so I'd be grateful for any information... /jason
You can't "hook" the dialog and really can't replace it. Why do you want to change the Save dialog in Word? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
You can't "hook" the dialog and really can't replace it. Why do you want to change the Save dialog in Word? RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
I want to intercept the message calling the Save Dialog and instead, open my own. Is this really an impossibility? The reason I am doing this is that I'm involved in a document management system and we want to prevent the user from doing certain things and allow them to do others. /jason
-
I want to intercept the message calling the Save Dialog and instead, open my own. Is this really an impossibility? The reason I am doing this is that I'm involved in a document management system and we want to prevent the user from doing certain things and allow them to do others. /jason
This is not impossible by any means, at least not up through Word 2002 anyway. I know nothing about Word 2003 but I would assume it still supports Automation. I have written something similar to what you describe - basically a document management type of application. We had documents that were stored on a remote server, users opened documents from a web page, and edited them using their local Word instance. Then we needed to trap the user save events in order to preserve the document names as well as launch an FTP transfer to automatically send the modified document back to the remote server. Basically what you have to do is get the active instance of Word, and then sink the events in your application. Word fires a DocumentBeforeSave event when the user attempts to save the document. If you set the SaveAsUI property to false in this event, it will suppress the Word Save Dialog. Then you add your custom code to control how the document is saved. That part is simple enough. There are some caveats: 1) If you always launch Word from your document control application, then you always have the reference and can sink events. But depending on your system, you may have to account for the possibility of a user launching Word itself then editing a controlled document. So your application may need to run all the time, and poll the system frequently to see if Word has been launched externally. 2) Again depending on your system, it may be possible for people to circumvent your controlled environment by copying/and or renaming controlled documents outside of Word - i.e using Windows Explorer. Obviously if you need to save a doc, users will have read/write access. So you cannot easily enforce this by file system permissions. You can trap this by using another feature of Word Automation object model. Documents provide a generic Variables collection. You can create your own variables that you can control by your code. For example, suppose you need to prevent a user from copying a document from Windows Explorer into a new file name and then editing it in Word. Embed the document name in a custom Document.Variable. When the user opens a document, you compare the file name to the embedded name, and if they don't match, act as you deem fit - i.e forcibly rename the document, close it as "corrupt", whatever. 3) This is MOST important: People use Word for a variety of reasons, and it is almost certain that only some documents will actually fall within the scope of your document control system.
-
This is not impossible by any means, at least not up through Word 2002 anyway. I know nothing about Word 2003 but I would assume it still supports Automation. I have written something similar to what you describe - basically a document management type of application. We had documents that were stored on a remote server, users opened documents from a web page, and edited them using their local Word instance. Then we needed to trap the user save events in order to preserve the document names as well as launch an FTP transfer to automatically send the modified document back to the remote server. Basically what you have to do is get the active instance of Word, and then sink the events in your application. Word fires a DocumentBeforeSave event when the user attempts to save the document. If you set the SaveAsUI property to false in this event, it will suppress the Word Save Dialog. Then you add your custom code to control how the document is saved. That part is simple enough. There are some caveats: 1) If you always launch Word from your document control application, then you always have the reference and can sink events. But depending on your system, you may have to account for the possibility of a user launching Word itself then editing a controlled document. So your application may need to run all the time, and poll the system frequently to see if Word has been launched externally. 2) Again depending on your system, it may be possible for people to circumvent your controlled environment by copying/and or renaming controlled documents outside of Word - i.e using Windows Explorer. Obviously if you need to save a doc, users will have read/write access. So you cannot easily enforce this by file system permissions. You can trap this by using another feature of Word Automation object model. Documents provide a generic Variables collection. You can create your own variables that you can control by your code. For example, suppose you need to prevent a user from copying a document from Windows Explorer into a new file name and then editing it in Word. Embed the document name in a custom Document.Variable. When the user opens a document, you compare the file name to the embedded name, and if they don't match, act as you deem fit - i.e forcibly rename the document, close it as "corrupt", whatever. 3) This is MOST important: People use Word for a variety of reasons, and it is almost certain that only some documents will actually fall within the scope of your document control system.
I think I'll bow out of this one gracefully! :-D RageInTheMachine9532 "...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
-
This is not impossible by any means, at least not up through Word 2002 anyway. I know nothing about Word 2003 but I would assume it still supports Automation. I have written something similar to what you describe - basically a document management type of application. We had documents that were stored on a remote server, users opened documents from a web page, and edited them using their local Word instance. Then we needed to trap the user save events in order to preserve the document names as well as launch an FTP transfer to automatically send the modified document back to the remote server. Basically what you have to do is get the active instance of Word, and then sink the events in your application. Word fires a DocumentBeforeSave event when the user attempts to save the document. If you set the SaveAsUI property to false in this event, it will suppress the Word Save Dialog. Then you add your custom code to control how the document is saved. That part is simple enough. There are some caveats: 1) If you always launch Word from your document control application, then you always have the reference and can sink events. But depending on your system, you may have to account for the possibility of a user launching Word itself then editing a controlled document. So your application may need to run all the time, and poll the system frequently to see if Word has been launched externally. 2) Again depending on your system, it may be possible for people to circumvent your controlled environment by copying/and or renaming controlled documents outside of Word - i.e using Windows Explorer. Obviously if you need to save a doc, users will have read/write access. So you cannot easily enforce this by file system permissions. You can trap this by using another feature of Word Automation object model. Documents provide a generic Variables collection. You can create your own variables that you can control by your code. For example, suppose you need to prevent a user from copying a document from Windows Explorer into a new file name and then editing it in Word. Embed the document name in a custom Document.Variable. When the user opens a document, you compare the file name to the embedded name, and if they don't match, act as you deem fit - i.e forcibly rename the document, close it as "corrupt", whatever. 3) This is MOST important: People use Word for a variety of reasons, and it is almost certain that only some documents will actually fall within the scope of your document control system.
This is what I'm talking about! Thanks for this Robert, it helped organise our thoughts on this process. What we have decided to do is implement an activeX control that hides the existing save button, and display our own in it's place, while leaving the Save As button in place. Our save button then saves the document to our DMS while the Save As button allows them to save documents with the usual interface. We're happy enough with this solution because it allows us to use the same ActiveX control for the Office Suite (Word, Excel, Powerpoint and Visio) Thanks for your tips /jason
-
This is what I'm talking about! Thanks for this Robert, it helped organise our thoughts on this process. What we have decided to do is implement an activeX control that hides the existing save button, and display our own in it's place, while leaving the Save As button in place. Our save button then saves the document to our DMS while the Save As button allows them to save documents with the usual interface. We're happy enough with this solution because it allows us to use the same ActiveX control for the Office Suite (Word, Excel, Powerpoint and Visio) Thanks for your tips /jason
Good luck!