Word has had this great feature for a while now, called Track Changes. You can activate it through the menu "Tools" --> "Track Changes" and in summary what it does is keep a record of the changes made to the document since you enabled this option. It will monitor deletion and addition of text, change of styles, insertion of tables, etc.

When you are working with VSTO and Word, unless you are forbidding your users to have "Track Changes" enabled (as if they will listen to you anyway ...), you have to write your code with the following in mind:

When you remove something from the document with "Track Changes" enabled (e.g. you select a table and press the "Delete" key), until you "Accept" or "Reject" the change, whatever it is that you removed still exists in Word's object model.

When you add something new to the document with "Track Changes" enabled (e.g. you type some text), what ever it is you added exists in Word's object model immediately, before you "Accept" or "Reject" the change.

You will need a second to think about the implications and how it affects you. Do not dismiss it as something trivial until you have given it some good thought. Let me give you an example of how it affected a project I worked on, in a way not thought of until the system testers caught it.

• The requirement was to have a textbox on a page, but for the textbox to exist only once on any given page. Code had been implemented that would detect the existence of this specific textbox on the page and not add a second one.
• The textbox was typically positioned on the right hand side of the page, on top of the margin, with text floating around it. In these situations Word uses an anchor to associate the object with a specific paragraph on the page.
• If the users needed the textbox to be moved to a different page, all they had to do was move the anchor to one of the paragraphs in the new page.

This was working quite well, until "Track Changes" got us! The scenario is simple, move the textbox's anchor to a different page when "Track Changes" is enabled. The result? When querying Word's object model the document now reported having two textboxes, one in the page the textbox was moved from and one in the page where the textbox was moved to. If the users attempted to add another textbox to the page from which they moved the original textbox from, our solution would complain that a textbox already existed and would not allow it.

The solution to this problem is to either educate users to "Accept" or "Reject" the change they have made (kind of tough as they have to know which specific pending change is causing the problem) or automatically "Accept" the change in code. We opted for the second option because we didn't think much of our users (only joking, it was not reasonable to request the users to do this manually) and this is the way we did it:

    // Go through each revision on the current page

    foreach (Word.Revision revision in pageRange.Revisions)

    {

        // Check if the revision is the deletion of the text box that

        // we have just found on the page

        if (revision.Type == Word.WdRevisionType.wdRevisionDelete &&

            revision.Range.Start <= currentTextbox.Anchor.Start &&

            revision.Range.End >= currentTextbox.Anchor.End)

        {

            // Accept the revision

            revision.Accept();

            break;

        }

    }