none
Word 2013 - Exception thrown on second document comparison RRS feed

  • Question

  • Hello,

    I am writing a VSTO add-in that allows users to easily compare two documents using Word’s compare function.

    Because I use the comparison result document after it has been generated I have been using _Application.CompareDocuments that returns a Document object and not _Document.Compare that returns nothing.

    Everything works as expected for the first comparison however when I attempt a second comparison the _Application.CompareDocuments throws the following exception

    Exception:           System.Runtime.InteropServices.COMException
    Message:            Error HRESULT E_FAIL has been returned from a call to a COM component.
    HResult:               -2147467259

    I am using:

    Visual Studio 2013 Update 3 (12.0.30723.00)
    Office Developer Tools for Visual Studio 2013 ENU 12.0.30626
    VSTO 4 runtime
    .NET Framework 4.5
    Word 2013 15.0.4605.1001 32-bit

    I have included some sample code below, if anyone can point out where I am going wrong that would be great.

    Thanks

    Richard

    Example:

    internal void StartCompare()
    {
        Word.Document CompareResult1 = RunCompare(@"C:\Temp\Compare\Doc1.docx", @"C:\Temp\Compare\Doc2.docx");
        Word.Document CompareResult2 = RunCompare(@"C:\Temp\Compare\Doc3.docx", @"C:\Temp\Compare\Doc4.docx");

        // Do something with CompareResult1 and CompareResult2
    }

    private Word.Document RunCompare(string OriginalDocPath, string RevisedDocPath)
    {
        Word.Document objOriginalDoc = null;
        Word.Document objRevisedDoc = null;
        Word.Document objCompareDoc = null;

        try
        {
            objOriginalDoc = this.Application.Documents.Open(OriginalDocPath, ReadOnly: false, Visible: false);
            objRevisedDoc = this.Application.Documents.Open(RevisedDocPath, ReadOnly: false, Visible: false);
                   
            objCompareDoc = this.Application.CompareDocuments(
                                            OriginalDocument: objOriginalDoc,
                                            RevisedDocument: objRevisedDoc,
                                            Destination: Word.WdCompareDestination.wdCompareDestinationNew,
                                            Granularity: Word.WdGranularity.wdGranularityWordLevel,
                                            CompareFormatting: false,
                                            CompareCaseChanges: false,
                                            CompareWhitespace: false,
                                            CompareTables: true,
                                            CompareHeaders: true,
                                            CompareFootnotes: true,
                                            CompareTextboxes: true,
                                            CompareFields: true,
                                            CompareComments: true,
                                            CompareMoves: true,
                                            RevisedAuthor: "Revision By X",
                                            IgnoreAllComparisonWarnings: true);

            ((Word._Document)objOriginalDoc).Close(SaveChanges: Word.WdSaveOptions.wdDoNotSaveChanges);
            ((Word._Document)objRevisedDoc).Close(SaveChanges: Word.WdSaveOptions.wdDoNotSaveChanges);
        }
        catch (Exception ex)
        {
            if(objOriginalDoc != null)
                ((Word._Document)objOriginalDoc).Close(SaveChanges: Word.WdSaveOptions.wdDoNotSaveChanges);

            if(objRevisedDoc != null)
                ((Word._Document)objRevisedDoc).Close(SaveChanges: Word.WdSaveOptions.wdDoNotSaveChanges);

            MessageBox.Show("Error: " + ex.Message);
            throw ex;
        }

        return objCompareDoc;
    }

    Thursday, July 23, 2015 8:40 AM

Answers

  • Hi Cindy Meister

    I have reported the problem to Microsoft and they have confirmed that it is caused by a bug in Word. The problem is that when I open the original and revised documents using “Visible: false” the Document objects return the wrong value for their FullName property. This causes the comparison (and I would imagine a few other things) to fail

    There are however workarounds, the first would be to open the documents and make them visible. This would be fine is not very user friendly, the second which is a little better is to create a new document before the compare i.e. Application.Documents.Add() this seems to force Word to get things together and then next documents I open using “Visible: false” works fine. I then close the new document that was created after the comparison has been run.

    As this has not been reported before and there is a workaround it is unlikely that it will be resolved any time soon. The bug is being documented and sent to the development team for consideration.

    Thanks for all your help with this

    Richard

    Wednesday, July 29, 2015 1:39 PM

All replies

  • Hi R.Grover

    I'm not intimately familiar with CompareDocument - meaning I don't know if there are idiosyncracies. But on thinking through your code that one thing that occurs to me is that objCompareDoc could be causing a problem. You return it, the object should go out of scope (in the .NET world), thus being available for garbage collection, and at the beginning of the function you set it again to null. Yet the document object is still open in Word and this could be causing a "hiccup" in the COM world (an open pointer).

    As a test, what happens if you do objCompareDoc.SaveAs, close the document, "null" it, force garbage collection and return the file path?


    Cindy Meister, VSTO/Word MVP, my blog

    Thursday, July 23, 2015 4:31 PM
    Moderator
  • Hi Cindy Meister

    Thanks for the reply, your suggestion of saving the comparison result and closing it did allow me to run a second comparison however the problem then is that the comparison result loses its connections to the original and revised documents meaning that when it is reopened they cannot be viewed alongside it as you would expect to do with a regular comparison.

    i.e. after the comparison has been executed the user is no longer able to select “Show Source Documents”

    Do you have any other suggestions?

    Thanks for your help with this

    Richard

    Friday, July 24, 2015 8:57 AM
  • Hi Richard

    OK, then we've isolated the reason for the problem - now we have to see if we can code around it.

    Next test: Is the Word UI able to support two Compare results simultaneously? Are you able, as an end-user, to perform one comparison, then another one the way you want your code to work? If the Word UI can't do it, you can't force it using code...


    Cindy Meister, VSTO/Word MVP, my blog

    Friday, July 24, 2015 3:10 PM
    Moderator
  • Hi Cindy Meister

    Yes I can run two in the Word UI it works just as I would expect it to.

    Thanks

    Richard

    Friday, July 24, 2015 5:03 PM
  • Hi Richard

    OK, the approach that seems to me most promising:

    Pass the document objects to RunCompare by ref and assign objCompareDoc to them. This will let you completely release (see my previous response, except for closing the document) objCompareDoc within the scope of RunCompare. (Note that RunCompare would then be void rather than return a Word.Document, or have it return something else.)


    Cindy Meister, VSTO/Word MVP, my blog

    Sunday, July 26, 2015 4:33 PM
    Moderator
  • Hi Cindy Meister,

    No luck unfortunately I still get the same exception. So far the only way around it I have found is to launch a new instance of Word and run the compare from there however this also stops me from being able to do other things with the documents.

    Do you have any other suggestions?

    Thanks for your help with this

    Richard

    Monday, July 27, 2015 7:20 PM
  • Hi Richard

    Could you please provide a set of documents, plus the code, to reproduce the issue so that we can do some testing?

    I did want to avoid, if possible, starting a new instance of the Word.Application...


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, July 28, 2015 3:45 PM
    Moderator
  • Hi Cindy Meister

    I have reported the problem to Microsoft and they have confirmed that it is caused by a bug in Word. The problem is that when I open the original and revised documents using “Visible: false” the Document objects return the wrong value for their FullName property. This causes the comparison (and I would imagine a few other things) to fail

    There are however workarounds, the first would be to open the documents and make them visible. This would be fine is not very user friendly, the second which is a little better is to create a new document before the compare i.e. Application.Documents.Add() this seems to force Word to get things together and then next documents I open using “Visible: false” works fine. I then close the new document that was created after the comparison has been run.

    As this has not been reported before and there is a workaround it is unlikely that it will be resolved any time soon. The bug is being documented and sent to the development team for consideration.

    Thanks for all your help with this

    Richard

    Wednesday, July 29, 2015 1:39 PM
  • Hi Richard

    Thank you for taking the time to report back what you've found out. That about the .Visible property is interesting and I'll bet it affects other things, as well...


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, July 29, 2015 2:26 PM
    Moderator