This content has been marked as final. Show 7 replies
There is certianly nothing "big" about a 2000 file project. People often use upwards of that limit although it is good practice to split large projects down and merge them. Does your project contain lots of links, images, DHTML or anything else that could slow things? It may be worth trying to create a few slave projects and merging them into a master. Before you go down that line though can you ensure the problem is not with your project. Open up one of the supplied "dummy" projects and try and compile that. Let us know what happens.
Very dumb question, but have you built a TOC with your individual topics in it?
RoboHelp for HTML will only generate .chm files based on what's in the TOC.
I've done the same thing as you in that I started in RoboHelp for Word and migrated over to Robhelp for HTML, so it's entirely possible to convert from one format to another.
Sorry Phil but the CHM will contain whatever is in the build and not all topics have to be in the TOC.
The only thing that excludes topics is a build expression.
Create one topic with the word Redrabbit in and include that in the build but not the TOC. Then search on Redrabbit.
You're right Peter.
Peter, thanks for your input. Here's where we are. We opened RoboHelp HTML and converted the Word docs into .html files. Then we were able to generate the .chm file (it worked this time) using RoboHelp HTML. We have about 50 .gif images, and no external links.
The actual number of HTML files with help topics is close to 4,000 for this F1 field help in our application. Ideally, we would love to have a master project with sub-projects, but it doesn't appear as a practical alternative. The .hh file (for F1 field help) is generated from the application by the developer and given to us.
In order to have a master project and slave projects, we would have to manually split that automatically-generated.hh file into individual .hh files, true? That means we would have to correlate which .html help topic file corresponds with which map id number, then chalk out how we want to divide the .html help topics into individual projects that correspond to their .hh files?
This help system I inherited is 10 years old, and the resource time we would spend (if we chose to modularize this help system) would be gigantic in scope. If there is a simpler and efficient way to modularize our F1 help system, I would love to hear about it!
What you say about the HH file sounds logical. CHM is not really my thing.
I don't think you need to actually split up the .hh file as all your F1 help can route through the master project. But size alone is not a reason to modularize your help. I have never seen any performance issues with a one .chm for every app approach. Our largest .chm compiles to 21MB, so I can't really say what might happen with a very large system but I think the sizes you report are 'typical' rather than 'large.'