none
TOC in OpenXML automated Docx only partially refreshing RRS feed

  • Question

  • Hey folks

    I've got here some documents generated using OpenXML SDK (2.0/2.5, same behavior). I've tried both MS Word 2010/2013, also same behavior.

    Now, I've got a TOC in the document which needs to be refreshed when the document opens. I use the 'UpdateFieldsOnOpen' flag to make Word ask the user to refresh his document. I then click 'yes, you may refresh'.
    -> Result = a partially refreshed TOC.

    Why partially? Well ... Content of the document is databound to a custom XML datasource using content controls. TOC at this point refuses to show the databound text, but instead shows the default text of the content control (which isn't really helpful).

    Now ... when I then manually refresh the TOC, then it does show me everything as it's supposed to be shown.

    Strange thing is that when the application was first made Word DID refresh that properly on document opening, so I'm at a loss as to why it's no longer doing so now. Maybe I'm missing something?

    Any thoughts would be welcome.

    Tuesday, July 29, 2014 2:56 PM

All replies

  • Hi,

    How do you use in your code to automatically recalculate fields on Open?

    I try to test the UpdateFieldsOnOpen in an existing document with TOC as followed in my Word 2013. After running the code and opening the document, it pops up "This document contains fields that may refer to other files. Do you want to update the fields in this document". If I click yes, it will let me update the Table of Contents. Then if I select "Update the entire table", it will totally refresh the TOC.

            public static void TestUpdateFieldsOnOpen()
            {
                string path = @"C:\Users\Documents\TestUpdateFieldsOnOpen.docx";
                using (WordprocessingDocument document = WordprocessingDocument.Open(path, true))
                {
    
                    DocumentSettingsPart settingsPart =
                        document.MainDocumentPart.GetPartsOfType<DocumentSettingsPart>().First();
    
                    // Create object to update fields on open
                    UpdateFieldsOnOpen updateFields = new UpdateFieldsOnOpen();
                    updateFields.Val = new DocumentFormat.OpenXml.OnOffValue(true);
    
                    // Insert object into settings part.
                    settingsPart.Settings.PrependChild<UpdateFieldsOnOpen>(updateFields);
                    settingsPart.Settings.Save();
    
                }
            }

    I failed to reproduce your issue. What do you mean by "partially refreshed TOC"? Would you mind sharing a screen shot or sample document through OneDrive to help us reproduce your issue and troubleshoot.

    In addition, what's the meaning "Content of the document is databound to a custom XML datasource using content controls"? Are you sure the content of the document is refreshed when opening. Since the update of TOC is based on the content of the document, I assume whether the content is not refreshed.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, July 31, 2014 6:09 AM
    Moderator
  • Sure, not a problem. I prepared some already.

    I believe this should be accessible to all:
    Default automatic TOC with second 'full refresh' question
    Example, SDK2.0, Word doesn't ask for refresh type here (assumes it's entire table)
    Example, SDK2.5, Word doesn't ask for refresh type here (assumes it's entire table)
    The same things, as a zip file (which I assume you'll need since the Word Online doesn't seem to allow open in Word)

    Thing is, a while ago I've seen this exact thing work (same document). I've also seen some other sketchy behavior with Word refreshing the TOC, so I suppose it's tricky business.

    Also, it's indeed that flag that I'm using to tell MS Word to refresh the TOC.

    And as for the databinding, as you'll see in the examples ... the document is automatically generated using the OpenXML SDK (2.0/2.5, tried 'em both) and is comprised of various altChunks and content controls which get their content/text from an XML datasource included in the Word file (the stuff under the 'developer' ribbon group).




    • Edited by Kevin VP Thursday, July 31, 2014 8:38 AM
    Thursday, July 31, 2014 8:33 AM
  • Hi Kevin

    "Any thoughts would be welcome."

    Mmm, my thought is that you're running into a "race" situation - the TOC is updating before all the other processing has taken place (updating the content controls from the Custom XML Part, for example). I have no idea whether the way Word works has changed, or whether you've "just been lucky" up until now.

    My recommendation would be that the same process that generates the document also writes the data from the Custom XML Part directly to the content controls.


    Cindy Meister, VSTO/Word MVP, my blog

    Monday, August 4, 2014 1:39 PM
    Moderator
  • Hi Kevin,

    You mentioned that it used to work for you earlier. Are you on the same machine and build on which it worked earlier? When was the last time it worked for you? What changed since that?

    Also on the client setting in Word set the option File -> Option -> Advanced -> General section -> check option 'Update automatic links at open'.

    You can refer to below link for the Open XML SDK FAQ
    http://social.msdn.microsoft.com/Forums/office/en-US/e53ae401-a698-4827-b6c4-6b4e5e50c3a1/open-xml-sdk-faq?forum=oxmlsdk

    Let me know if it works for you.

    Regards,

    Monday, August 4, 2014 7:10 PM
  • Alright, sorry for the late return folks. I kinda broke my knee and it's been tough the past few weeks.
    In any case, tnx for the information so far.

    I checked the setting 'update automatic links at open' and it's indeed checked in the options.

    As for when it changed exactly I can't say since I don't know. When I built the solution I tested the functionality, offered it to the customer etc. At that point it did in fact work.
    I'm still running the same laptop as last year and my development server has not changed either. The only thing I could think of is certain updates that might have made changes to the processing logic of Word. (either via Office service packs or Windows update)

    Now, that's not to say I didn't experience quite a few issues 'getting it to work'. Although now, those initial issues I had I cannot reproduce anymore since it's always this.

    Back when I was developing it I had a similar issue where the whole TOC would be generated except the last line would be like this, unbound.
    I managed to fix this by adding in an extra 'empty' document chunk at the end after which it would manage to also process that last line of the TOC.

    Basically ... I haven't found a way to get it working yet so far.

    The comment Cindy gave does make sense though. MS might have changed the order in which the processing is done and now Word is first updating the TOC before binding the data, but it's not like there's nothing in the TOC, so after running through the document content.

    However ... if this is the case, what are my options then? Does that mean it simply can't be done?


    • Edited by Kevin VP Tuesday, August 26, 2014 10:21 AM
    Tuesday, August 26, 2014 10:21 AM
  • Hi Kevin

    "Sorta" broke your knee <snort>? I hope it's healing well and thoroughly!

    Your options:

    1. Run the document through Word Automation Services (runs on SharePoint, on-premise) - that should be able to force the field updates and is one of the purposes of WAS (http://blogs.msdn.com/b/brian_jones/archive/2010/02/09/leveraging-the-power-of-word-automation-services-and-the-open-xml-sdk.aspx)

    2. As I suggested in my previous reply, construct the TOC result in the document. This can still be part of the TOC field, so that the user can make changes and it will update, if that's a requirement.

    FWIW, I've since discussed this informally with an MS person, which confirmed that my guess is pretty much on-target. There's nothing in the design of how Word opens and updates document content that can guarantee that the TOC update takes place after all other content has been processed.

    As best I can see and recall in this discussion you never mentioned "chunks" before. If Word is having to integrate altChunk files, that would certainly be an unpredictable factor in the speed and order in which Word executes things when opening a document...


    Cindy Meister, VSTO/Word MVP, my blog

    Tuesday, August 26, 2014 2:29 PM
    Moderator
  • Well, let's just say the first few weeks were the most painful, but I'm still on crutches.

    1. I did indeed consider WAS before. However ... since the customer only uses SP as a document storage database, I'm limited to using the free version. I do understand it would be a bit extreme for a customer to have to pay the full SP Standard licence costs for 1 functionality. Technically, my company could host a full blown enterprise SP installation with only 1 user license and use a custom online service based architecture to take advantage of the WAS services, but I don't see that happening any time soon. Also, the customer hosts everything in house to prevent sensitive information from being lost, so they probably wouldn't like that either.

    2. Do you mean to literally assemble the <w:p> paragraph tags and all it's content that I see generated after the TOC has been refreshed and the document is saved?

    With all those matching 'textId' properties and PAGEREF references that the TOC now generates when updating it?

    In this situation it's nice if it can be manually updated by the customer after they make a change, but that's less than likely to happen since the generated document is overall also the final document so the most important thing is that the layout, titles and page numers are accurate.

    And yes indeed, there are some AltChunks in the document. Those titles that are databound are actually contained in an AltChunk the first time the document opens after generating it.

    Tuesday, August 26, 2014 4:22 PM
  • Hi Kevin

    <<2. Do you mean to literally assemble the <w:p> paragraph tags and all it's content that I see generated after the TOC has been refreshed and the document is saved?

    With all those matching 'textId' properties and PAGEREF references that the TOC now generates when updating it?

    In this situation it's nice if it can be manually updated by the customer after they make a change, but that's less than likely to happen since the generated document is overall also the final document so the most important thing is that the layout, titles and page numers are accurate.>>

    The big problem is going to be page numbers - it's almost impossible for you to generate those "on the fly". Otherwise, it could be a static TOC (no fields). The only other idea would be to link a VBA project into the document (docm, then, not docx) with an AutoOpen macro to update the TOC and see if that triggers late enough that Word has had time to integrate all the altChunks so that the information is available.

    A variation on this approach would be to attach the document to a template that contains the AutoOpen macro. That's more easily trusted and can be code-signed. Or a VSTO or COM add-in that monitors the DocumentOpen event.


    Cindy Meister, VSTO/Word MVP, my blog

    Wednesday, August 27, 2014 4:47 PM
    Moderator