I have a RH8 .chm called by the application by specifying the filename of the .htm file in the project. So, their tag HelpContext="MyTopic" would display the associated MyTopic.htm in the .chm project. This makes me believe that somewhere in the .chm is a list of filenames of the original sourcefiles, yes?
In order to support a multi-author environment, we've sorted the html files into subfolders under the project's top folder. The project compiles file. But, the application can't seem to find the MyTopic.htm in the compiled .chm project.
I tried taking one of the subfolders, copying it and creating a new "child" project from it, deleting the original subfolder from the main/master project, and inserting the child project into the "master" project. Again, the "master" project compiles file, but again, the application can't find the relevant MyTopic.htm file in the .chm file.
Does anyone have insight as to what's going on inside the .chm file? Any way that I can break the 1 project into multiple "child" projects (so that multiple authors can work on various parts of the documentation) and yet have the original filenames retained, w/o any sort of subfolder string being (apparently) attached to it?
Any and all clues are appreciated.
I believe your folder structure is duplicated in the chm file. So if everything was in the root folder, then the application only needed to call the specific file name. Now the application will need to include the path. For example:
In the Toolbox Pod is an app called "HTML Help Studio" which you can use to investigate the content of a chm.
You might want to investigate Context Sensitive Help which allows you to map a number to a file, getting around any problems of path changes. It would require changes by your developers, but that will be required anyway from the sounds of it. There is some information in the RH help file which you may or may not find useful.
Thanks! I did some poking around on the web, and was coming to the same conclusion about the folder\filename issue.
Do you know if a similar issue applies to merged projects? After discovering the problem with folder/filename usage, I tried a merged project, but seemed to have the same problem with the HelpContext="filename" strings.