none
Intermittent Word Issue with Content.MSO folder RRS feed

  • Question

  • We have a Windows application that has a form with a WebBrowser control that is used to display Word documents to the user for authorisation. Our form has an ‘Authorise’ button for the user to click that they are happy with the content. When they click this we automatically add some text to the letter as follows:

    1. Clear the WebBrowser control to release the document
    2. webDoc.Navigate "about:blank"
    3. DoEvents
    4. Set myWebdoc = Nothing
    5. DoEvents
    6. Use Word Automation to open the document from a UNC path on a server folder share
    7. Add the text using Word Automation
    8. Save the updated document back to UNC share path with appwd.ActiveDocument.Save

    Step 8 seems to fail intermittently on pcs with Windows xp sp3 and Word 2010.

    The error returned is:

    5253 Word did not save the document.

    C:\...\Content.MSO\5FDAB558.doc)

    Queries

    Our code does not use Content.MSO.

    1. Why is the Content.MSO folder being used in the above process?
    2. What causes the 5253 error?
    3. Can this error be prevented?
    4. Can we disable the use of Content.MSO folder?
    Tuesday, October 29, 2013 8:56 AM

Answers

  • Hi Nick

    Isn't Content.Mso located in a "temp file" path? If the file isn't stored locally, Word has to cache a copy locally in order to open it and work with it. That would explain the file path, I think...

    No idea what is causing the error or how to prevent it - there are too many factors we can't know about involved in what you're doing. BEst you could probably do, at this point, would be to make sure the instance of Word you're automating is Visible and that you allow all alerts to be displayed. In that state, you might get a message through the Word UI that gives you more information. (Also, make sure you're using Try...Catch blocks to ensure that the maximum information is coming back to you.)

    Strictly speaking, you're trying to work with Word in an "unsupervised" state - not interacting with the user. This is always tricky with Office applications; they weren't designed to be used like that. So things can go wrong, especially when networks are involved. For example, there might be a "hiccup" in your network connection that causes the problem.

    A much better approach, if we can assume the *.docx (instead of legacy *.doc) file format, would be for you to work directly with the document's Word Open XML. This can be done without the Word application being present - your code works on the closed file. The approach uses the standard Packaging and XML namespaces, you can even use the Open XML SDK, that makes the task much easier since it abstracts the zip package contents and XML. That should certainly solve the issue you're experiencing.


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, October 29, 2013 7:06 PM
    Moderator

All replies

  • Hi Nick

    Isn't Content.Mso located in a "temp file" path? If the file isn't stored locally, Word has to cache a copy locally in order to open it and work with it. That would explain the file path, I think...

    No idea what is causing the error or how to prevent it - there are too many factors we can't know about involved in what you're doing. BEst you could probably do, at this point, would be to make sure the instance of Word you're automating is Visible and that you allow all alerts to be displayed. In that state, you might get a message through the Word UI that gives you more information. (Also, make sure you're using Try...Catch blocks to ensure that the maximum information is coming back to you.)

    Strictly speaking, you're trying to work with Word in an "unsupervised" state - not interacting with the user. This is always tricky with Office applications; they weren't designed to be used like that. So things can go wrong, especially when networks are involved. For example, there might be a "hiccup" in your network connection that causes the problem.

    A much better approach, if we can assume the *.docx (instead of legacy *.doc) file format, would be for you to work directly with the document's Word Open XML. This can be done without the Word application being present - your code works on the closed file. The approach uses the standard Packaging and XML namespaces, you can even use the Open XML SDK, that makes the task much easier since it abstracts the zip package contents and XML. That should certainly solve the issue you're experiencing.


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, October 29, 2013 7:06 PM
    Moderator
  • Hi Cindy 

    Thank you for the reply. Unfortunately we have to work with the legacy .doc format so Open XML is not an option. The error is intermittent but quite frequent so I don't think it is a network issue (other network stuff seems to work fine). If I copy the file locally, edit it with Word Automation, and then copy it back, will this avoid the use of Content.MSO and therefore possibly be a workround? Or have you any other ideas? Ideally I want to trace the cause of the problem but have found very little about error 5253 other than an apparentlly unrelated FTP issue. 

    Thursday, October 31, 2013 4:24 PM
  • << If I copy the file locally, edit it with Word Automation, and then copy it back, will this avoid the use of Content.MSO and therefore possibly be a workround?>>

    I don't know, you'd have to try it... If my guess is correct that mitght help.

    <<Or have you any other ideas? >>

    Not really.

    Just FYI: I don't think point 4 in your original message is achievable: Word / Office requires it in order to correctly cache things and would probably create another one if you locked an existing folder.


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, November 6, 2013 6:54 PM
    Moderator