Issue with blank Index, but TOC works and content is viewable

[Tech_Writer_KC]

RH7, .chm help files, one parent, multiple children, all local to each machine

I'm starting to run into an issue with our Help system where the TOC works (you can see topic titles and view the contents), but the Index is initially showing up blank.

As the users view topics through the TOC, they show up on Index. Here's the exact comments from one of our support staff:

"Table of Contents Works and content seems to be there as you drill into topics.

Index is empty initially.  After I navigated to some screens in the Contents, those pages now show in the index.  Search on several common words all returned No Topics Found.  I noticed that the Apexext.chw file changed date/time and now has the Archive attribute set."

Anyone have an idea as to what's going wrong here? My local manually built help system works fine, and tests fine on others machines. The issue seems to be with the help coming out of TFS for our install CDs, including one set of help files that were auto-built via TFS command lines on our build machine, and a set of help files that were manually created by me and checked into TFS, which our CD guy then checked out to put on the CD.

I should point out, we're getting the issue with local copies of help on XP, Vista, and Windows 7 machines (local help), as well as with Server 2003 and 2008, so AFAIK it's not a network issue, nor somehow specific to an OS.

Sorry this is so open-ended, I've just no idea why things aren't working all of a sudden. Maybe it'd help to list out my questions:

1. Any ideas/suggestions as to what might be the cause of the index being blank? Keeping in mind the following:

-the TOC works fine, and content is viewable, i.e. not an issue that completely disrupts links or viewing between the parent and child. Only the index seems affected.

-once topics are viewed through the TOC, they are being added to the Index via the .chw file. So that behavior seems normal, so to speak.

-again, local files, so not a network issue.

-happens on both Vista and 7, so doesn't appear to be an OS issue.

2. Does anyone have experience with automated help builds? Is there any reason to suspect that storing the chm files in TFS, or running RH via command lines is causing this?

The way our automated build works is that we have a build machine with TFS and a copy of Robohelp. The stuff I work on gets checked into TFS. When the auto-build runs at 5am, TFS checks out the RH files, then uses command lines to open RH and then open each RH project and generate the .chm files. When it finishes, the project files (including the new .chm files) get checked back into TFS. When we make install CDs, the .chm help files are grabbed from TFS. Sometimes, if last minute changes are needed, I'll manually do them and check in the new .chm files. Either way, the CD guy gets them from TFS.

3. Anyone with experience with CD burning? Is there any possible way burning to CD can cause this? It's worked in the past, and I don't think anything's changed on the CD burning end.

Only bring it up as the only two consistent details we know so far between the two help builds that have this problem is that they are both .chm files grabbed from TFS and then installed via CD. As I mentioned above, one set of files was auto-built via our build machine, the other set were manually built by me and checked into TFS. We're currently resolving the issue by FTP'ing them the same help files, which after they manually install resolves the issue.

Thanks for any help given. We were all set to upgrade to RH8 (finally), but that's been burnered until we get this sorted out.

[Tech_Writer_KC]

Update: some odd behavior discovered, not sure if it helps much.

One of our testers decided to write a basic test to verify the index is working on our help files in TFS. The test basically opens the Help, tabs to the Index tab, and then counts the number of words in the Index window. If it's less than an arbitrary amount (25 words), sends an error message.

In testing the test, he happened to open and close the help file a number of times, and in the process the index magically returned. I say "magically" because we have absolutely no clue as to how, what, or why that happened.

Just thought I'd pass it on in case that provides any clues.

[Tech_Writer_KC]

*bump*

Anyone have ideas here? Even just guesstimates as to what could cause the kind of Indexing errors we're encountering would be helpful.

[MergeThis]

[Relying solely on remembered posts, because I don't work with .chm output or RCL...]

• There might be an issue if one of the merged .chm's doesn't have at least one Index entry?
• Does RCL only run properly if the layout has been run via RH at least once? (This might apply as well if any layout has been updated for any reason, and would therefore need to run via RH once again.)

Might be no help at all, but hey...

Good luck,

Leon

[Tech_Writer_KC]

1. All the individual projects have index values.

2. It's possible, but none of the layouts have been changed.

The only changes we currently make to our Help projects is adding, editing, and deleting topics. What has made this so odd is that we simply cannot pinpoint what's changed elsewhere to cause this effect in the Index and Search, especially given that the TOC works fine and content is viewable.

It's like the Index and Search can only see the parent file, but the TOC can see everything as normal, and I can't find anything to explain such a targeted restriction of what the parent file can 'see'.

Also difficult as it does not seem to be consistent in terms of where it surfaces or not. We can't limit it to an OS, for example, and I'm not aware of any recent MS updates that would interfere here. Again, the closest thing to a consistent detail we're seeing is that my manual builds seem to work fine, whereas anything built automated or even manually-built .chm files checked into TFS seem to manifest this behavior.

Deep down in my heart I still suspect some sort of viewing rights issue, but unless I can provide smoking gun evidence, support and customers want to blame RH for this issue.

[MergeThis]

errr...actually, I think I'd be pointing to TFS. But that's just me.

Hey, even RH's own source control (RSC 3.1 on RH8) gives us indigestion from time to time

Good luck,

Leon

[Tech_Writer_KC]

I would, but the problem is that none of our development projects are encountering any issues. Without some parallel weird behavior in other projects, or some sort of smoking gun evidence that TFS can affect even finished .chm files, there's no way for me to shift the blame off RH.

[Peter Grainge]

I cannot see how anyone can blame RoboHelp for a problem where the same file works on some PCs and not others. If RoboHelp were the cause, does it not stand to reason that the file would be flakey on all machines?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Tech_Writer_KC]

The problem is that I'm the lone tech writer, thus the lone user of RH. If no one else experiences issues with TFS/etc., it gets ruled out because the only files with problems are coming from RH.

Additionally, the problem is not consistent. I cannot point to it and say "only XP users are getting this", or "only the users at this one computer or customer site", or etc etc etc. I can't point the finger at an OS, or a customer's user/viewing rights environment, or to shared/similar/simultaneous/parallel problems with other programs being maintained in TFS or built with FinalBuilder.

The other issue is that this appears to have started only several months back. There's just no simultaneous change in our build environment, TFS environment, etc. to account for this, nor of course any simultaneous issues cropping up in other programs that could point to some sort of external source triggering this. Not that we've changed our RH installs or projects (beyond working with topic files), but I simply cannot point the finger away from RH when I have not a single shred of non-RH evidence to indicate there's been a change or whatever outside of RoboHelp.

The fact that my manually-built local files work 100% vs. the issues cropping up with automated builds or TFS-stored files may be a consistent detail, but for the rest the #1 consistent detail is that this is only a Help issue, thus the finger is pointed at RH, and because I can't even figure out what's causing the issue, let alone fix it, I have nothing to counter that claim. I can't tell them it's a non-RH issue when I can't even fathom a guess as to what's causing the issue. I NEED a smoking gun, consistent and clear evidence that points away from RH for me to say it's not an RH issue, especially given the track record (predating me starting here) of RH being a buggy or problematic software and the related issues it's caused our Help system in the past.

Sorry, not meaning to vent. It's just that life was going pretty good until this issue emerged, and now I have an unsolveable issue staring me in the face every morning for who knows how long.