none
Issue (and dilemma) with Overwriting Header/Footer bookmark with TrackChanges enabled RRS feed

  • Question

  • Hi,

    There's a specific scenario in Word, that my add-in programmatically adds a bookmark that encloses a text that is for consumption of the add-in; which works fine for almost a decade now.

    However, with a new feature I've implemented: that is, the add-in being aware if TrackChanges is enabled and the revisions, there's this scenario that when using Insert->Footer->Blank, overwrites the entire footer including the programmatically added bookmark (by looking at the list of bookmarks, it won't be listed anymore). And this is fine, as "normally" it will "update" the modified bookmark to the expected text or re-adds the bookmark if it doesn't exists (by a certain event; like during saving, or something else.)

    [When I say "normally" above, it means by MANUALLY modifying the text, deleting the bookmark the add-in knows how to handle this scenario and acts appropriately.]

    However the following are observed VISUALLY:

    1. After a certain event that inspects the bookmark and its content, there's no update whatsoever.

    2. Listing existing bookmarks, and it isn't there. [this is expected as long as it won't conflict with the #1 below]

    and PROGRAMMATICALLY (C#):

    1. The bookmark, by name, can still be retrieved.

    2. The bookmark content, (i.e.; myBookmark.Text) is still intact with the expected string.

    3. There is no Revisions in the bookmark range itself, or the range whatsoever. [If ReviewPane is displayed, you won't see any from the time the Insert->Footer->Blank is selected so this is in-sync.]

    My feeling is that this is a MS bug, but is there any workaround or suggestion(s) to try?

    Issue found in: Word 2007/2010/2013

    Cheers,

    John

    Tuesday, September 9, 2014 3:17 PM

All replies

  • Could you share a document for us to understand you more?

    Wednesday, September 10, 2014 8:44 AM
  • Hi John

    I think I'm following what you're saying... To figure out where this is being retained it would be necessary to investigate the WordOpenXML of such a document. Or if you're able to give us a set of repro steps we can use to quickly duplicate the situation?


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, September 10, 2014 5:53 PM
    Moderator
  • Hi Cindy,

    Assuming you have an add-in running:

    1. Enable Track changes. Open the Review Pane as well so that you can easily see the changes Word tracks.

    2. Your add-in then inserts the bookmark with your preferred name into the footer. [P]

    3. Also, assign a certain text in the bookmark, let's say "Footer Test". [P]

    4. Verify your bookmark from the bookmark lists.

    5. From the menu, Insert->Footer->Blank. [If you open the Preview Pane as mentioned in step #1, you won't see the bookmark text being deleted.]

    6. List the bookmarks again. Your bookmark is not there anymore; while from step#4 it was there.

    7. From here, let your add-in traverse through your footer range, and locate the bookmark added in step #2. ISSUE: You'll still find your bookmark (search by name) and the string "Footer Test" is still accessible. [P]

    *** At this point the bookmark should have been deleted and so cannot be accessed via simple traversing of bookmarks. Also, you should be able to find the "deleted" objects via the Revisions collections with revision type = DELETED. Unfortunately, this object will be empty as Word did NOT track this (as attested by the Preview Pane.)

    More importantly, step #7 is the crucial part. Since if the add-in does NOT find the bookmark, it is easy to put it back by creating a new bookmark and assigning the string (pretty much re-doing step #2 & 3.) But because it found the bookmark and the content the same (i.e.; bookmark1.Text == varTextToAssign) the add-in will not to "touch" it.

    However, the user doesn't see the text "Footer Test" anymore as the it has been functionally & visually deleted.

    *** Steps that are bold (but it doesn't seem to display right) are programmatically done. I added the symbol [P] at the end of the step to signify programmatic, compared to you doing it manually.

    I hope these steps are sufficient for you to reproduce the steps.

    Cheers,

    John


    Cheers, John


    • Edited by z00mBeE Monday, September 22, 2014 6:47 PM lack info
    Monday, September 22, 2014 6:43 PM