There are a couple of things to try:
1. Do your clients get the !SSL!\Microsoft_HTML_Help\ folder as shown in your image? Or do all the chm files end up in the one directory? If they will all be in one directory, then you need to get rid of the path definition in the TOC. If the child projects will be in different directories in the end product, then the path should reflect this. I suspect your chms should be something like:
Symyx for Excel
2. I'm not sure if the book issue is still a problem, but to test, in your TOC add a book above your merged help files, so it looks something like this:
Symyx for excel
3. Your Scrivo hhc filename contains spaces. This might cause issues. If the project window is defined to point to a different hhc file, then maybe you can just delete that from the dialog box and save the "table of contents.hhc" file to the same name as your project (scrivo.hhc). I'm not sure about this - someone else will hopefully chip in with more information.
4. If none of those fix your issue, you could try recompiling all the children without underscores in the chm name. And if that doesn't work, renaming the project to remove the underscores in the hhc filenames (I think renaming the project does this, but I'm not 100% certain).
Hope this helps.
Thanks for your help. There are some things you said that I need explained.
-- "Do your clients get the !SSL!\Microsoft_HTML_Help\ folder" Are you asking me if the child .chm files are in this folder? Yes.
-- The child .chms all end up in the same folder in the parent !SSL!\Microsoft_HTML_Help\ folder. In a merged help system, all the .chms (parent and children) need to be in that folder for it to build.
-- " ... you need to get rid of the path definition in the TOC." -- please explain this and give an example.
Let's start with these questions for now.
When you have a directory path in the TOC, that means that the directory structure should match. So for example:
TOC (in parent.chm)
End folder structure: (+ for folder, - for file)
Now if the symyx_client file shows up okay after the error message, possibly the parent chm file is smart enough to correct for the directory structure not being there, but a file with the correct name existing in the same directory as the parent.
We've always tried to ensure out merge references don't have a path - RH has the annoying habit of requiring the chm file to be copied into the root, but we just delete it after the first build, as it shouldn't need to be there for the actual compile process. In fact, we've had problems with the chm being physically built into our parent chm, drastically increasing the file size and resulting in duplicate and outdated topics in search. We leave the file there for the first build as sometimes the merge doesn't work first go without it; I think it has to do with how it gets added to the hhp file.
To test that our merge works, we just copy a couple of the files into the same folder (e.g. c:\temp\test) to double-check. We need this process as our clients get different combinations of the total chm files built into our parent.
Something else I've just thought of is maybe there is something strange happening in the actual hhc file. Do you have any topics in that TOC with characters other than a-z, 0-9 and underscore in the filename (in the topic title should be okay, but maybe some particularly odd ones might cause an issue)?
Hi. Just noticed that one of the child .hhc files is named:
See the spaces "Table of Contents.hhc"
Would that cause the problem?
Thank you all for your good suggestions.
We live in a world of interdependent and integrated (somewhat) software applications.
Here's what the problem was: my Windows system profile was corrupted!!! One of our wonderful IT guys logged in using his system profile and the .chm file opened with no error message.
On to the next challenge ...