Multiple CHM Table Of Contents

[Mark51172]

Hi all,

I was wondering if someone can advise me on something I'm attempting to do. We've recently moved on to html from Winhelp so not entirely au fait with how it works.

I am building a new help system and currently have 5 chm files. Each chm file has its own table of contents. The first of the chm files is the "top" file and is the one that users will open first of all. The idea is that they will be able to link from there to the other chm files (which I've linked as remote topics).

What I want to do is make it so that when they open that first chm file, the TOC displays all the TOCs from the other chm files. Also I would like to be able to search and find words/topics within all the other chm files.

Is this possible? From what I've read on the internet I believe it is but I can't find an "idiot's guide" as to how to do it. I don't have much coding experience so it's a bit of a learning curve. I have tried open the hhc file for the first chm and adding links to the other hhc files, but that doesn't seem to have had any effect.

Hope this makes sense to someone and thanks in advance for any pointers you can give.

Regards,

Mark Jones

[MergeThis]

In the RH Help, see Single Source Layouts > Default Layouts > Microsoft HTML Help > Creating merged HTML Help.

You won't need any coding experience.


Good luck,
Leon

[Mark51172]

Cheers Leon, hadn't spotted that page. Does just what I wanted.

Regards,

Mark

[Phil_Wells]

Having just beaten my head against the same wall, several things that might help. (Robohelp X5).

(1) When you merge .chm files, you can update the content on the .chm files by overwriting the imported files with newer versions. However, this only updates the text/images in the topics - it does not update the table of contents if you have added new topics, etc.

If you've updated the TOC in the subsiduary .chm files, it's as well to rebuild the master project from scratch by making a clone of the original master project. (I do this by keeping the master project down to just 3 - 4 topics, then it's easy to recreate a copy when you rebuild.

(2) Make sure you have the indexes present in all files before you merge. In particular, if you don't have an index entry in the master file, no combined index will be generated.

(c) See Also's of the same name in different .chm files will be combined when the files are merged.

If you have an "Introduction" See Also in each subsiduary file, you will end up with a single massive "Introduction" See Only in the final output.

[RoboWizard]

Hi Phil

Regarding your suggestion of rebuilding the master because you aren't seeing an updated TOC, there really should be no need for this. The Master TOC doesn't actually contain the TOC for the sub(s). It only contains a pointer that looks for the sub. If the sub is found, it reads in the TOC at that time. So all you should have to do is update the sub and things should be fine.

I'm wondering if you are seeing something different in preview and making an assumption you need to recompile the master. There is an issue with RoboHelp where it pulls in the current sub, but doesn't propagate the same to the output folder. But I never test a Master/Sub this way anyway. I always test by copying to a different folder.

Cheers... Rick

[Phil_Wells]

Hi Rick,

I've shed some further light on the problem that might interest you. I'm in RoboHelp X5 and compiling as HTML output.

I've got a series of sub-projects, which I load into the master. Tthe Robohelp Help files suggest that if you compile the sub-projects and import them into the master, then if you keep recompiling any changes in the sub-projects, when you recompile the master, it should include all changes in the sub projects as well.

What happens is that if you recompile the sub project, neither the changes in content nor TOC are picked up when you recompile the master. This applies even if you delete the imported TOC from the Master TOC and delete the .chm file from the baggage files before reimporting the .chm file and its associated TOC. I've even tried deleting the reference to the merged file in the .hcc file:

<param name="Name" value="FileA.chm::/FileA.hhc">
<param name="Merge" value="FileA.chm::/FileA.hhc">

Even more bizarely, if you look at the re-imported (recompiled) sub module via windows explorer it has the changes, yet when you recompile the master, it shows the old (pre-recompiled) version of the sub module. i.e the reimported file has updated, but the master project retains a memory of the older (outdated) file, despite it having being deleted.

I've now found the answer. When you recompile the master product it writes the master .chm + all the sub-project .chms to the specified output sub-directory. What happens is that RoboHelp doesn't overwrite any older copies of the sub-project .chm files that are in the output sub-directory. Accordingly when you look at the output, you see the older .chm sub projects, not those you have re-imported into the master project.

If you go to the output sub-folder and delete any .chm files present before recompiling everying works as it should - the required sub-project .chm's are written to the (now empty) sub folder. (This is a variation on your comment of "There is an issue with RoboHelp where it pulls in the current sub, but doesn't propagate the same to the output folder".)

(You also have to re-import the re-compiled sub-projects into the master before re-compiling the master - RoboHelp doesn't automatically look for updated versions).

[Captiv8r]

Hi Phil

Unfortunately, I must have done a poor job of explaining the issue. I say this because you are describing the issue I meant to tell you about.

Specifically:
I've now found the answer. When you recompile the master product it writes the master .chm + all the sub-project .chms to the specified output sub-directory. What happens is that RoboHelp doesn't overwrite any older copies of the sub-project .chm files that are in the output sub-directory. Accordingly when you look at the output, you see the older .chm sub projects, not those you have re-imported into the master project.

What you are describing is not a variation on the issue I mentioned, it *IS* the issue.

Again, I can tell you that when I deal with Master/Sub files, I never test by simply running the master from where it ends up. I always copy the Master and subs to a different folder before I test. And I can tell you I've never encountered any issues by doing things this way. I test this way because it's the closest to what the end user will see and any issues present should arise here.

I would suggest you try it this way. Compile your subs. Then compile your master. Now copy all the subs and the master to the arbitrary folder. Now simply recompile a sub and plop it inside the arbitrary folder. Open the master and note that you do not have to recompile the master to see the changes. They simply appear by virtue of having a new sub in there.

I know I've argued the point before. Some call it a flaw in RoboHelp that compiling doesn't overwrite the subs. I say why not simply point the output location for each sub to be the output location of the master? Since they aren't deleted during the process, they should be fine there. And always show what you expect.

Just a thought... Rick

[Phil_Wells]

Thanks Rick,

One of two more questions for you if you would be so good....

1) What faults might you find if you compile in a copied folder? I tend to send a compiled file to one of my colleages and get them to open it onto their computer - it's one reason we realised you needed to ship the HHactiveX.dll file with every build.

2) I tend to produce several versions of every file with the aid of conditional build tags; a generic one, one or more customer specific ones, and a version for technical support, where we include information we don't want our customers to see.

The only way I've found you can get conditional build tags to work in a merged file is to compile the different versions of the sub-modules, then import the required ones into the specific build.

I can see what you are saying about pointing the output location of the sub-modules to the appropriate directory of the master - if the master has three outputs, then if I point the appropriate versions of the sub-modules to the appropriate folder in the master's output folders, I should have permanently up to date versions of the different versions of the Help Files.

Are there any pitfalls I should watch out for with this approach?

(BTW, thanks for your input - it's most helpful)