QUESTION: Is there a way for RoboHelp 11 to combine (Not Merge) multiple CHM files into a Single CHM file; if so, how?
When users are using our 1099 Utility (Standalone version) help file (a.chm) and select’s (hit F1) a certain screen, the help topic, such as, the Transaction Review screen in the a.chm file, hence, the system can't locate it because it does not exist in the a.chm file. However, after I copied the b.chm (our AP application help) file in the bin directory where the 1099 Utility deploy's to, then the correct topic is found.
Note: This works properly on a mainline build because that build includes both a.chm and b.chm files. However, it does not work in the 1099 builds because it has only a.chm and this file does not contain a topic for this screen. The a.chm file has this topic. The problem is that the mapping between the Transaction Review screen that is open from 1099 Utility does not request the topic with this topic's ID that is specific for the a.chm.
Attempts made by the developers to reconcile between the application code and the a.chm help ID mappings to properly address the issue. However, I'm told it cannot be addressed in the code; the alternative approach is to start including the b.chm file with the 1099 Utility deployment. However, it is not a desirable solution.
Attempts to find a solution
FURTHER INQUIRY: Are there any other utilities (not mentioned above) that could combine several separate chm files into one large chm?
Is the content that becomes a.chm and the content that becomes b.chm maintained in separate RH projects?
Hello, and Yes.
When I read "Attempts made by the developers to reconcile between the application code and the a.chm help ID mappings to properly address the issue. However, I'm told it cannot be addressed in the code;" I would guess that your developers don't have two versions of the Transaction Review screen in their source code. They might have it set up where, at the screen level, the screen doesn't know if it's in your standalone utility or within your 'integrated' system. Thus, the F1 key is always going to go to the Transaction Entry topic in your a.chm file.
And since you have these in separate projects, I also guess that there's a business reason they were created as separate projects. If that is true, the easiest solution to combine the individual RoboHelp child projects into a single Monster RoboHelp project, is not an option. I'm guessing that's the case because you're trying to work with the output (the CHM files) of your RH projects, not the input (project) level.
Sorry, I don't have a magic solution to take away your issue.
I can tell you that, years ago in the WinHelp days of having 100 WinHelp files that I merged at runtime with a master.cnt, I had a somewhat similar situation. There were some global topics that I wanted to be used across all the files but, like you, I didn't want to distribute the whole doc 'library' as a solution. What I ended up doing was finding those 'central' topics that I wanted to be accessed across all of the .hlp files and putting those into a smaller .hlp file with only those specific topics. Is it possible to take the Transaction Review screen help topic out of the b.chm project and put it into its own RH project and generate its own .chm file, which you could then distribute with your 1099 Utility (Standalone version) help file (a.chm). I don't know if you have a lot of topics that are in the same situation or not - it may end up creating more of a headache than it's worth.
I can also tell you that when I converted those 100 WinHelp files to HTML, I was going to have individual projects for the different types of systems (Financials was one; Trouble & Plant Management was another; Service Orders was another). It was going to break down to having around 5 different projects. The trick, though, was that there was a lot of cross-referencing and such. Eventually, it became obvious that combining the files into a single RH project made the most sense. Again, that's just my experience when dealing with cross-references and calling help from the application.
Maybe this helped, maybe not.
Thank's Paul for taking the time to provide guidance. I thought about the same suggestion (ref. looking for cross-reference help topics and importing them (HTMLs) into the TOC / a.chm project, and possibly getting adding the mapIDs to the BSdefault.h file). Gee, if some created a working utility that we envision, it would be great!
Why is having all the CHMs in one folder to allow the use of merged help an issue? My first though was because in some scenarios only some of the programs are installed but if that's the case, only their help would be required.
Could the developers instead of installing each CHM within its program folder creating a separate folder within program files for the CHMs and call them from there? Might not fly but I thought it worth asking.
See www.grainge.org for RoboHelp and Authoring information
Moving the other chm (e.g. b.chm) into the application folder where a.chm resides during deployment is not a big problem perse'. This already happens when the customer has several accounting applications of ours installed. However, installing this particular application as a standalone product, only the help file for it (e.g. a.chm) is deployed. A work ticket was assigned to me to look into other options and the solution guidance if you will, suggests only have both chms as the last resort. My inquiry for this matter is to further research and to rule out all other options. More importantly, learning new and prefer ways using Rh has helped.
As always, thank you for your expertise.
I'm not sure we are at one on this. My suggestion is that within program files you have something like:
You would install only the products for that customer but the help could always contain all the help or such components you need.
See www.grainge.org for RoboHelp and Authoring information
Certain screens in the 1099 app call other accounting application (e.g. AP), hence, clicking F1 on a specific screen (e.g. Invoice Inquiry) triggers the mapping ids for the ap.chm file. Usage as such, the user can further research - - drill for a history on an invoice, etc. As for generic use (1099 Utilitystand-alone purposes), the user would just run 1099 and reports.