Compiler caching obsolete topic names

[gewriter_2]

This is a really strange issue, and we've done troubleshooting in every way we can think of, so I'm hoping someone here has a new idea. Here's the issue:

1. We have topics that were originally created in RoboHelp as web help files.
2. These files were converted to html and then to Flare.
3. These files were copied to a second project.

These topics all have a header and H1 of 'Assign X.' They appear just fine in the original project. In the second project, a subset of the topics have a header and H1 of 'Assign X,' but when you compile the help and do a search, they show up in the search results as 'X'.

I've tried deleting my temporary internet files and cleaning the project and rebuilding, with no luck. I've also tried creating a brand new topic within Flare (no content copying), and deleting the old topic. This also failed. I've even gone in and compared the HTML code between the same files in project 1 versus project 2. They are absolutely identical. My best guess at this point is that the issue is with the compiler caching a title, or somehow pulling a title from who knows where. Does anyone have any ideas on how to solve this issue?

[LTinker68]

If I understand what you're saying, the search results are returning a topic title of "X" instead of "Assign X"? If that's the case, try opening one of those topics in the Internal Text Editor and see if there is a <title>... </title> group of tags. Normally, Flare determines the title of the topic based on the first heading it finds in the topic, like <h1>Assign X</h1>. However, if there is an actual set of <title>... </title> tags in the topic code, then the value between those tags overrides the value between the <h1> tags for things like the search and index features. If that's the case, then you'll want to do a find-and-replace in Flare using regular expressions to delete all the <title>... </title> tag sets from all of the topics (make a copy of the project first, just to be safe).

[gewriter_2]

If I understand what you're saying, the search results are returning a topic title of "X" instead of "Assign X"? If that's the case, try opening one of those topics in the Internal Text Editor and see if there is a <title>... </title> group of tags. Normally, Flare determines the title of the topic based on the first heading it finds in the topic, like <h1>Assign X</h1>. However, if there is an actual set of <title>... </title> tags in the topic code, then the value between those tags overrides the value between the <h1> tags for things like the search and index features. If that's the case, then you'll want to do a find-and-replace in Flare using regular expressions to delete all the <title>... </title> tag sets from all of the topics (make a copy of the project first, just to be safe).

Thanks for your reply. I've already gone in and verified that the topics all have a <title>...</title> group of tags. I even tried creating a new topic from scratch, with the 'Assign X' <title></title> and <h1></h1> tags, and the search is still showing the same thing. This indicates to me that it's an issue with the compiler itself, rather than with the source code.

I also did a search for all instances of 'X' within the code, and came up with nothing.

[LTinker68]

Actually, I was suggesting removing all <title>... </title> tag sets.

When you compile, are you deleting the entire Output folder before building? Every time you compile, Flare creates a new set of search*.xml files. Maybe your browser is caching those files. I tend to delete the Output folder before building because it tricks browsers (especially IE and therefore conceivably the HTML Help) into think that it's going to a new site so it won't load cached data.

[gewriter_2]

Actually, I was suggesting removing all <title>... </title> tag sets.

When you compile, are you deleting the entire Output folder before building? Every time you compile, Flare creates a new set of search*.xml files. Maybe your browser is caching those files. I tend to delete the Output folder before building because it tricks browsers (especially IE and therefore conceivably the HTML Help) into think that it's going to a new site so it won't load cached data.

I see. Sorry for the confusion. Given the number of topics in my project, this is definitely a last-resort solution.

I clean the project before every build. I've also tried deleting my temporary internet files first, then deleting all the output folders, then emptying my recycle bin. All of the files are in a source control, so I've also had another coworker try to build (using all the housekeeping steps listed above). He also had the same issue.

[forfear]

Have you tried running
C:\Program Files\MadCap Software\MadCap Flare V4\Flare.app\Resources\Bin

And running RegisterItcc.bat


not sure it if this is anywhere near a solution but i thought, this is something new to do perhaps.

[gewriter_2]

Have you tried running
C:\Program Files\MadCap Software\MadCap Flare V4\Flare.app\Resources\Bin

And running RegisterItcc.bat


not sure it if this is anywhere near a solution but i thought, this is something new to do perhaps.

I have not tried either of those. What exactly would they do? (We're almost ready to release the help, so I'm not as free to experiment as I would be earlier in the project.)

[forfear]

It simply reregisters a required HTML help component ...works when the search button doens't seem to be returning any/or relevant results even after searcching a few rounds.,..

[KevinDAmery]

That may be worth a whirl, but I don't think it's the same thing. When ITCC.DLL gets unregistered usually the search doesn't turn up anything at all. This is more a problem of the title shown for the results not showing the complete title of the topic: the search itself is producing results, it just doesn't present them with their full titles.

[GregStenhouse]

I would recommend decompiling the CHM, and have the look at the actual files that are being compiled. You can use HTML Help Workshop (File>Decompile) for this, and FARHelp also has tools that use can use to examine CHMs.

In the files that are decompiled, search (windows seach would do) for files containing text "X" (or "<title>X") and see if it finds anything. If you do find files, look at the code and see if that provides any clues.

If searching fails to find anything, then this is most definitely a strange issue, and one that probably requires re-installing stuff

Cheers
Greg

(btw, re-registering the help components can't hurt, and certainly won't cause you any problems)