I had the problem with one chm constantly falling out of the merge. To fix that, I had to manually edit the xpj file in a text editor, ensuring all (correct) chms were listed in the <mergedhelpfiles> tag. The format should look like this (in RH6, but I think should be the same in RH9):
HOWEVER. I think this might force the hardcoded paths problem, for which the only workaround I found was to double-compile every time I needed a new parent. If you're using Peter's setup with almost no content in the parent, then, I believe this should be fairly infrequent.
(Double-compile = Compile. Open hhp and delete hardcoded paths. Recompile.)
Anyway, see if this is any help
1 person found this helpful
Regarding the separate window for child chms, I seem to recall a setting somewhere that configures the window to use for the TOC. Possibly in the Output definition in an Advanced button somewhere.I don't have access to RH just at the moment to check.
Thanks for that. Actually, I didn't quite go down the redirect path, instead I latched onto the fact that only upgraded projects have the problem with merged help, not projects created in RH9.0. Even so, in the freshly created project, the XPJ file contains the line:
however, the file rhmhelp.apj does not seem to exist!
- I create a brand new project in RH9 HTML and import all of the original html files and TOC.
- I delete the merged projects links from the TOC, select New Merged Project and remerge those chms from an external folder.
- When I compile once, ALL content opens in the parent window
- The HHP file contains the heading [Merged Files] and lists all the merged CHMs using a relative path
- The XPJ file contains the following line but no entries for the files themselves:
- If I compile again, the [Merged Files] section is deleted from the HHP file and the content for the merged projects opens in individual browsers.
This is seriously doing my head in and the release deadline is looming.
Try manually adding the merged chms into the xpj like I suggested in my first post.
Tried amending the .xpj file and as suggested and compiling the collections to an external topic. Reviewed the HHP file and as suspected, it does indeed hard-wires an absolute path to the child chm files.
I am open to suggestions. I have rebuilt the parent so many ways now and nothing seems to fix this.
Unfortunately, I think if Peter's solution for a permanent fix didn't work, then the double-compile is the only workaround I know of. At least with that method you do get the merge to work.
I'll just list the steps in full:
1. Compile the help.
2. Open the hhp file in a text editor.
3. In the MERGED FILES section, delete all the paths, leaving only chm file names.
4. Recompile in Robohelp.
Edit: Actually, I just re-read, and the merge is still working, just opening in a separate window? I'll try to track down that setting I mentioned earlier.
Okay, I don't have RH9, but check in a location similar to this.
Open the single source layout you use to build you chms. Make a note of what you have set for Default Window. There should be an Advanced Settings section or button. Open that dialog box. There should be a TOC Settings tab. Check that the Default Window on that tab is either <Default> or the same window name you made a note of earlier.
See if that helps with the opening problem.
We upgraded to RH9 about 9 months ago. Prior to our upgrade, we were using RH7. Our Help solution consists of one parent project with 30-some merged children. In RH7, we had the issues that everyone else has with the full file paths appearing in the HHP file, and we used the “double-compile” solution mentioned here to work around it. Unfortunately, the double-compile solution does not work in RH9. No matter how many times you edit the HHP and recompile, the full file paths appear in the output.
We thought for a while that we had found a solution. Over time, we had stopped following the typically workflow for merging projects. So we backed up and started over, using the recommended steps. After merging all the children into the parent using this method, the merge list in the HHP file was fine. Over time, however, especially when more than one person used the parent project (we have 5 different writers), the full file paths would come back, and the only way to fix them was to re-merge the children.
But I think we may have found a solution. It’s another workaround, but I think we’re going to try it for a while as it’s preferable to the alternative (re-merge every time we need to compile). If anyone else tries it, please post back here to report your success/failure. I’m a little concerned that this new workaround may introduce new issues that we just haven’t seen yet. I’ll post an update if we encounter any new problems.
Here’s our process.
- Open the XPJ in RoboHelp, compile, close project.
- Open the HHP in Notepad, update merge list with a clean list (file names only, no paths). Save.
- Delete the CPD file.
- Delete the XPJ file.
- Open the HHP file in RoboHelp (XPJ file will be recreated automatically).
- Check the HHP file—the merge list should be what you saved in step 2, and the output should work fine.
A couple things to note:
- We do NOT have the child CHMs in the parent project folder. They’re just in the output folder.
- The steps above work for a single user. If another user opens the XPJ file created in step 5 above and compiles, the merge list in their HHP file will contain the hard-coded file paths. But they can perform the steps above to get a clean HHP.
Ha! Well now that we’ve got it working, I’m not sure that I want to tempt fate by installing an update. You say “allegedly.” Do you know anyone who has tried it?
As the originator of this thread, I would like to point out that I believe my woes are at an end (he says bravely).
Despite following all the tips and tricks and workarounds (thanks to all those who responded), none proved to be a lasting success (even with 9.0.2).
The only solution that worked was to copy all of the chm files into the root of the parent, remerge them all and then compile the parent; the resulting chm file works fine with all content displaying in the single parent window (relative paths). Even editing the parent and re-compiling was a success, HOWEVER, closing the project proved fatal. Upon reopening the parent and re-compiling, absolute paths were re-established!
Now the good news. There have been a couple of Adobe updates, unfortunately I tend to just accept them and get on with things so I don’t know what they were or what they fixed however, my absolute/relative path issue has now been resolved! I can close and recompile to my heart’s content and all is as it should be.
Whether there was a RH update or an Acrobat update that changed some shared file(s) I neither know or care, I just wish that Adobe hadn’t “improved” that functionality in the first place, which caused such grief.
Currently, my RH build is 220.127.116.111 and it works. I am however, reluctant to install any more RH updates, at least on my main machine. As the old saying goes, “if it isn’t broken, don’t fix it!
SRH Systems Ltd
1311B Melton Road
Tel : +44 (0)116 260 1051
Mob: +44 (0)776 929 8519