Skip to main content
Inspiring
July 30, 2009
Question

"Synchronize Table of Contents" stops functioning in output at one point

  • July 30, 2009
  • 4 replies
  • 2841 views

Greetings,

I am publishing as WebHelp and the TOC/Navigation synchs and displays where I am in the documentation as I navigate using "Previous" and "Next" links within each content page.

Up to a point. Then it fails, And it continues to fail even where it had worked before.

The page where the synch breaks down and the page whose "Next" link leads to it, but can find nothing wrong. I have tried deleting the page where the synch breaks down and creating a new file in its place and a new TOC link in the project, to no avail. I have also tried deleting and recreating the entire TOC (which is quite extensive and the auto-generate makes a hash of it which is very time consuming to fix -- but that's another story).

So, what is going on with the synch display at this particular juncture. I can see nothing remarkable in the source code for either the page where the synch breaks down or the page with the "Next" link that opens it. Nor do I have any idea why the whole synch display breaks down and stops after reaching this one page even where it was working previously.

Attached is a zip of the output files. The file with the "Next" link is in a folder named "Chapter_5_Google_AFV_Ad_Campaigns" and the file itself is named "Section_II_CreatePlaceholder_forNewCampaign.htm." The file where the TOC/Nav synch fails is in a folder called "Chapter_6_ScanScout_ Ad_Campaign" and the file is named "Section_I_CreateNewCampaignforAdvertiser.htm"

I'd provide a link to the online Help but it's in a protected staging server.

Ideas? Solutions? This is urgent.

Thanks.

Steven

This topic has been closed for replies.

4 replies

stevenjsAuthor
Inspiring
August 3, 2009

The question is answered, but there is no interface to designate my own response as the "correct" answer.

As I said, " I renamed the existing RH project folder, created a new RH project using the same name as the old, created new folders to match, and imported all the old html files into them, and but for a few adjustments to the prev-next nav, everything came out hunky dory."

That's closer to an answer than any other.

Thanks.

Steven

MergeThis
Inspiring
July 31, 2009

No, I'm not kidding; see how your zip file is still labeled QUEUED? That means that it remains unavailable for download until the censor/monitor determines that it does not contain anything offensive/dangerous.

As to the TOC thing, I'd delete the pages under that "Chapter 6, Section I" book, and then the book itself, and recreate it. See if that helps. I kinda think, though, that the whole numbering thing might be problematic. Since your chapters might get restructured as the documentation evolves, numbering seems counter-productive, as well.

Are you aware that:

  • The Topic Title and File Name entries do not have to agree (General tab of Topic Properties window).
  • The Topic Title  does not have to agree with your Heading 1 title within the topic.
  • Once you have established a book (with or without a link to a page) and pages in the TOC, you can rename those TOC entries to anything you want.

Therefore, you could have:

  • TOC entry "New Campaign Placeholder Creation"
  • Topic Title "Create_Placeholder_for_NewCampaign"
  • File Name  "cre8_phold_new_camp.htm"
  • Heading 1 title of "Creating a Placeholder for a New Campaign"

Once we can get a look at that potentially dangerous zip file, we might be able to help more.

Good luck,

Leon

Captiv8r
Legend
July 31, 2009

LOL - I'm not sure I'd call it censoring. But I suppose it technically fits the bill.

I usually refer to it as a forum moderator having to approve it.

You say toe may toe, I say toe mah toe...

Captiv8r
Legend
July 31, 2009

Hi again

I should also add that there are free services that allow transfer of files. Adobe themselves offer a service using Acrobat.com

Click here to visit Acrobat.com

Or, you could use YouSendIt or TransferBigFiles

Click here to visit YouSendIt

Click here to visit TransferBigFiles

Cheers... Rick

Helpful and Handy Links

MergeThis
Inspiring
July 30, 2009

Your zip file probably won't be cleared by the censors until tomorrow, but my first reaction was: holy crap! Those are some reeeealllly long folder & file names!

Also, is "Chapter_6_ScanScout_ Ad_Campaign" a typo, or do you really have a space betweeen "Scout_" and "Ad_Campaign"? If so, not good...

Good luck,

Leon

stevenjsAuthor
Inspiring
July 30, 2009

Thanks, Leon. Was a space. Good catch.

But removing it has not caused any change in the problem.

In other guides where everything works, the file and folder names (vs. the titles as they appear in the Nav/TOC) are even longer.

Another issue I neglected to mention at the outset, not only does the synch no longer work once one gets to Chapter 6, Section I, but one can no longer open any of the "books." The whole Nav gums up.

What's this about "censors?" Are you kidding?

Steven

Captiv8r
Legend
July 30, 2009

Hi there

Try editing your WebHelp Single Source layout properties. Click the next button twice and configure the speed optimization to Local PC. Then generate again. See if this solves your issue.

Cheers... Rick

Helpful and Handy Links

stevenjsAuthor
Inspiring
July 30, 2009

No, it doesn't. Don't see why it would either.

Are we down to "computer voodoo" with this?

Captiv8r
Legend
July 30, 2009

Hi again

stevenjs wrote:

No, it doesn't. Don't see why it would either.

Are we down to "computer voodoo" with this?

Not really. Here was my line of thought. Remember that your Single Source Layout is equivalent to a recipe that governs the "ingredients" that end up in the output. As each page is modified it is injected with different bits of JavaScript. One of the scripts injected (assuming the Single Source Layout recipe has included it as an ingredient) causes a script to fire that handles synchronizing the topic with the TOC location.

When the typical settings are used, the TOC data is broken into many smaller byte sized chunks during the WebHelp generation process. When the user loads up the WebHelp, the first layer of books loads into the TOC area. Once complete, the second layer loads and so on. Because this happens in stages, occasionally a link is clicked early on that attempts to synchronize the TOC to an area that hasn't been loaded yet. In that case, no synchronization will occur because the data simply isn't there.

By configuring the WebHelp recipe Speed Optimization to Local PC, you are telling WebHep to keep the TOC data in a single larger file. And this often corrects the synchronization issue we hear about.

Your issue may be completely different, which probably explains why the setting seems to have no effect in helping your situation. But there you have it. The full monty on why I suggested what I did. (Since you pondered why the setting would even matter. )

Cheers... Rick

Helpful and Handy Links