Bug Word 2010: Documents collection is not correctly maintained
A person in the Word for Developers forum brought an important bug to our attention last week. When documents are opened/created then closed the Documents collection does not keep proper track. The index value is not reduced correctly (there are more documents in the collection than there should be) and some document names are missing while others are duplicated. (The thread with repro code sample can be found here.)
The Documents collection is not some obscure object – it’s central to file maintenance. That it does not function correctly is a serious issue. Microsoft appears to have been aware of it for some time, but hasn’t bothered to document the issue or correct it in Word 2010. The Documents collection does, however, work correctly in all previous versions and in Word 2013.
I began to look for a reasonably efficient and reliable workaround and stumbled on an interesting fact: If the NewDocument, DocumentOpen and DocumentClose events are actively being monitored by an add-in that loads with Word, the repro code yields the correct results – the Documents collection functions as it should.
It does not matter whether this is a COM, VSTO or VBA (document template) add-in. And the code in the events doesn’t need to do anything special or useful. Just the fact that the events “trigger” from the very moment Word starts seems to keep the Documents collection “honest”.
If you’re a VBA programmer, go to the VBA Editor and activate the ThisDocument module from the Normal project, “Microsoft Word objects”. In the code window, select “Document” from the dropdown list on the left.
A stub for the event Document_New will be created immediately. From the list on the right, also select Document_Open and then Document_Close. You can type in a commented line explaining what this is for. Save the changes, quit the VBA Editor and quit Word. The next time you start Word the Documents collection should function correctly.
Here’s my test code:
Private Sub Document_Close()
'Keeping the Documents collection working correctly...
End Sub
Private Sub Document_New()
'Keeping the Documents collection working correctly...
End Sub
Private Sub Document_Open()
'Keeping the Documents collection working correctly...
End Sub
April 5th, 2013 at 19:19
Hi Wordmeister, sorry for the long delay responding to your question.
I did try the workarounds but I recall it didn’t work in my situation.
When the operator opens a letter, it may have what we refer to as trigger letters. The operator can delete a trigger letter but now because of this problem, instead of closing the document I insert a Watermark into the document stating the letter is flagged for delete. If operator closes and later reopens letter, letters flagged for delete are not opened.
This solution has been working very well without any problems. I am hoping there is a service pack with fix to this bug. I don’t think management would want to upgrad to Word 2013 just for this bug.
Do you know if there is a Service Pack availble for this bug in Word 2010?
April 11th, 2013 at 09:35
Hi Curt
I don’t think this has been addressed in any currently available Service Pack, or whether it ever will be. A company with a heavy-duty support contract could possible force Microsoft into creating a hot-fix for the problem. If that ever happened, the hot-fix might be incorporated into a Service Pack, but it’s not guaranteed…
February 25th, 2013 at 17:58
Hi everyone, I see this is a relatively new post and wanted to share with everyone the problem I am having.
My application automates word 2010 and opens multiple documents. When a document is closed, the collection of open word documents is not right. After the document is closed, a loop through the collection reveals the first document opened is missing from the collection. However, one of the documents is listed twice.
This is a major problem! Short of closing and reopening the documents after a document is closed, I don’t have a work-around yet.
Please Note, the program code to manage the open documents resides in a VB.Net project with COM Interrupt turned on. Word Macros with VBA code make a call back from Word to the VB.Net application. A parameter is passed indicating the function to perform, e.g. Delete Document. I am going to see if using the work around mentioned above by adding the Document_Close event will work in my case.
Is there any chance Microsoft might have a Service Pack to resolve this bug? Any help or suggestions for what to do would be greatly appreciated. Going to Word 2013 might be the best way to resolve this issue, but that won’t happen fast enough at my work.
Thanks in advance for any help anyone can provide.
March 15th, 2013 at 19:07
Hi Curt
Have you tried the workarounds mentioned in this article? As far as I know, they’re the only options you have.
February 4th, 2013 at 12:09
Hi cchimi
I believe I answered your question of January 25 in the Word for Developers forum on January 28 – http://social.msdn.microsoft.com/Forums/en-US/worddev/thread/a91e8ee3-5181-4107-a518-402382305683
If you can’t make changes to the Normal template for everyone concerned, then I believe you have to invest in a COM add-in, as I mentioned in my post of November 9. It was testing a VSTO add-in that lead me to the “workaround” using Normal.dotm for people using VBA.
Has your company a Visual Studio .NET license for the Professional or “higher” edition?
February 15th, 2013 at 18:20
Hi, didn’t realize this was your site. We do not have a Visual Studio license; I only have access to VBA for this project.
Since there doesn’t seem to be another solution, I’ve disabled the ability to work in more than one document at a time. Not ideal, but the best I can do for now.
Maybe I could programatically update the Normal template for users? That seems risky, though.
February 18th, 2013 at 17:28
Hi cchimi
Mmm, yes, fiddling with the users’ Normal.dotm carries certain risks with it. How feasible the idea is would depend on how much people really use Normal.dotm? These days, the only things really stored in Normal are macros and any styles people have chosen to modify on a more permanent basis.
If they’re savvy VBA users you could probably ask them to copy/paste the code in, themselves.
If not, is Normal.dotm stored locally or in a network location? And how many users are we talking about?
February 18th, 2013 at 22:11
Thanks for the response. This is something that will be provided for clients, so we don’t control or have access to their Normal.dotm files at all. Some of them are likely savvy enough to insert the code (and it would be simple enough to provide a tutorial). Others definitely won’t, even with a tutorial, but your suggestion is worth considering. If I can provide that as an option, it might suffice. I wonder if I could check Normal.dotm and only ‘turn on’ certain features if the code was found. Sounds like a 2.0 feature!
February 20th, 2013 at 10:19
You can check the Normal.dotm if access to VBA is enabled on the client machine. This is the VBE (Visual Basic Extensibility) library. This is deactivated by default as it’s a security risk (Macro viruses).
The only other way would be via the Open XML document “package”. I would have suggested this as “the” right way, if it weren’t for the fact that VBA is stored in the old proprietary, binary file format which isn’t easily readable. If you have advanced programming skills, however, that would be the best and most reliable approach. As a matter of fact, you could probably use it to add the code to Normal.dotm…
NOTE: I don’t check in here regularly, so this kind of discussion really would be better in the MSDN forums.
January 31st, 2013 at 19:53
Any chance something else is required to get this to work with a VBA add-in? The steps above don’t work for me; my Documents collection is still FUBAR. Someone on the msdn forums suggested that not all events trigger in a VBA add-in, and that the event code needs to be in Normal, but I can’t make changes to the Normal template for other users.