Can you search children topics for merged CHM files?

[Guest]

We have a master project with 58 .chm files, but freetext search only finds info on topics from the master CHM output.  Is there a way the master .chm or the individually merged .chm files can be configured so the Search function will drill down to the children CHMs?

[Amebr]

In the source of your master project, could you open the .hhp file and check in the [MERGE FILES] section (should be at the bottom) whether there is a full path to the child chm files, or just the child chm names? Assuming all the child chms live in the same directory as the parent, only the chms should be listed, otherwise the search will look for the children in the listed path (which probably isn't the location on your users' PCs.)

As the last step before we finalise our help we do the following:

1. Compile the help.

2. Open the hhp file in a text editor and delete the paths from the [MERGE FILES], leaving only the chm file names.

3. Save and close the hhp file.

4. Re-compile the help.

Hope that helps,

Amebr

P.S. I assume if they don't live in the same place, relative paths would achieve the same effect. However, I think having merged chms living in different directories could be problematic.

[Guest]

Worked like a charm. Got our whole little documentation team all excited.

A thousand thanks.

Jimmy

[Guest]

We've tried this a hundred times (slight exaggeration).  RoboHelp overwrites the HHP file with the absolute paths.  That breaks the build -- I can verify that search looks at the absolute paths, and does not use the CHM children that I ship with my help.  This means that I can't deliver a merged help -- unless I ship my hard drive along with it.

I find it very disturbing that RH overwrites my changes to the HHP file.  If I take the trouble to put in relative paths, that's because I want relative paths. But RH thinks it knows better.  I consider this a bug -- a data loss error -- and it should be a show-stopper.  Nobody should ever ship software that destroys the user's data.

Please, if I'm mistaken on this, somebody let me know!!!  I'm actually quite desperate, lots of money, and lots of time is riding on this.  I can get the MS Help compiler to respect my relative paths, but then I have to struggle through it's special understanding of the TOC and other info.  That means I have to duplicate my work.  I'm not sure why RH costs what it does if it also costs me so much to use it...

Signed...  a Merged Chump.  (that was a joke...)

[Guest]

I have to update the state of the union...  We did get this to work by following the described steps to the letter.  In other words, you open the project, generate the master CHM. edit the HPP WHILE THE PROJECT IS STILL OPEN, then generate again.  It seems RH assumes it must update the project from its database whenever you first generate the project for a session.  For subsequent generate actions it seems to assume that everything must be in sync, and you must have made all changes through the GUI.

LET'S HOPE THEY ALWAYS MAKE THAT ERRONIOUS ASSUMPTION.  Otherwise, this workaround will be killed, and you will not be able to deliver your CHMs without also delivering you hard drive.

I saw in other discussions that you can open the database in Access and edit the paths to make them relative.  Opinions vary as to whether this will "stick", or whether RH will just decide you really want absolute paths, even after you edited the database.

Let me repeat, this is an egregious bug.  At the very least, Adobe should own up to it and get it into the release notes.  The end result is that you cannot ship merged CHMs without also shipping your personal file structure.  In other words, you cannot ship merged CHMs.  Adobe should either fix this, or simply admit that they don't support merged CHMs.

Let me tell you, I have spent far too much time trying to get this project to work.  I can't wait to see what the next expensive surprise will be.

Still feeling like a chump...  But thankful for the people who posted this workaround here.

[Guest]

They way we work our files is the parent and children CHMs all reside in the same directory when we ship so we delete the path completely from the HHP file and leave only the CHM name and extension e.g. copy_database.chm. This makes for a clean Global Search. To save time from deleting all the erroneous path garbage in the HHP, I've recently made a text file that has all the CHM names in it, and I just paste over the garbage under so it's completely clean. This has to be done after all changes are complete.

In other words: (1) complete all changes in the Master CHM, (2) generate the master CHM, (3) fix the HHP file by having only file names (with extensions) under , and then (4) generate the master CHM again.

If this gave you a headache, I hope you don't use more than one product from the same RH project, because we've had major problems when we have more than one TOC and more than one Window in use in the project. I recently found an install when 55 merged CHMs were nothing but dead links from the master, this took me 16 hours to solve, and it turned out to be the last child CHM in the project was the offender, but there was nothing visibly wrong, just a bug in RH that has something to do with the default settings for the Window.