Update Table of Contents Using Macro

[clhare]

I am working on a template that contains a Table of Contents. Since the templates macros will be removing paragraphs throughout the document, the TOC needs to be updated before the macro ends. Is there a way to do that accurately via macros? I've tried using the following code, but while it does update the TOC, the page numbers still aren't correct unless I update it again myself.

ActiveDocument.TablesOfContents(1).UpdatePageNumbers


Any help is greatly appreciated!

[Tinbendr]

What about just .Update?
ActiveDocument.TablesOfContents(1).Update

[clhare]

I tried that and it still doesn't update the numbers correctly. There's a macro command that works if I use that after the template's macros have run, but I need to find a way to access that command by macro.

[Frosty]

Need a little more info, Cheryl. The difference between .Update and .UpdatePageNumbers is simply whether or not to update whether there are missing paragraphs or not.

If you're removing paragraphs, you definitely want to use .Update.

However, it sounds like it's either a timing issue (there are other things happening after you run the .Update which affect the page numbers), or you might have some specific formatting going on (lots of hidden paragraphs or some other bit of formatting which can give Word fits in determining proper page numbers).

What is the macro command that works that you need to find a way to access? When are you attempting to update the TOC?

The short answer: it should be working. But there are a lot of times when it might not work-- especially when you are interacting with other code. Do you have access to the template code? Or are you attempting to tack your code on at the end of other code?

[Tinbendr]

What about adding
ActiveDocument.Repaginateafter the update?

[clhare]

I am removing paragraphs... a lot of them potentially. I have the .Update code near the end of the macro, just before I turn screen updating back on and relock the template (so the user can tab from form field to form field once the macros are done. Adding a repaginate command didn't help.

The easiest I could make it for the user to fix the table of contents was to add the "UpdateTableOfContents" command to a toolbar. When I click on the toolbar button, I then have to select the "Update Page Numbers Only" option.

There is hidden text all over the place in this template (instructions the user wants in the document for various paragraphs that they want to see on screen but not print). Why would that stop the macro from updating the TOC correctly, yet I can do it with the toolbar command after the macros are done?

Sounds like I may have to just make the user update the TOC with the toolbar button.

[Frosty]

Well, it might be a bit simpler than that. Have you tried running the macro with screen-updating turned on, just to test?

[clhare]

Ok, I updated the code so the macros will update the TOC after turning screen updating back on. It seemed to work correctly if I didn't protect the document before the macro ends (so the user could tab from field to field). But I noticed there were fewer pages in this file than in the one I generated where the macro did protect the document at the end.

So I did a document compare between the two files to see why the total number of pages was different and... they were exactly the same. I found that if I saved my "correct" file and reopened it, the file repaginated and the TOC is incorrect again. It did the same thing whether I had repaginated before updating the TOC in the macros or not.

So, I'm back to using a toolbar and making the user update the TOC after the macros are all done.

YIKES!

[Frosty]

In protected doc scenarios, the pagination may not take into account the content of the form fields when the doc is unprotected... That could be why there's a difference. Does it not work to update the TOC after re-protecting?

There really should be no difference on timing, from what you're describing, unless other code is interacting with it.

But protected documents have always been a bit quirky... I think that's one of the reasons MS created content controls

[clhare]

Nope, you can't update the TOC after the document has been locked. Word is very quirky!!

[fumei]

That is not quirky. It makes perfect sense. It would not make sense if you COULD update TOC when the document is protected.

[Frosty]

So maybe you should re-protect (preserving data), then unprotect, update the TOC, and reprotect again.

From what you're describing, Cheryl, there is no reason why you can't do something to accurately update the TOC within a single routine. Adding a button to do it as a separate process should have no effect on accuracy. If it does, then there is something else going on that you're not aware of or not describing (external code running when you open a protected document, etc).

[fumei]

I agree. It may take a bit of wobbling back and forth to achieve - and in that Word IS quirky - but I see no reason it can not be achieved within one procedure.

That being said, the fact there is a great deal of hidden text DOES touch on quirkiness. Hidden text, and possible content within the formfields can make differences in pagination.

I also agree that if there are significant dicrepancies it is quite possible there is somethng else going on that has not been mentioned.