Skip to main content
T
Tech_Writer_KC
Known Participant
March 31, 2011
Question

I give up - how are parent/child .chm links maintained?

  • March 31, 2011
  • 2 replies
  • 2591 views

I've been following the letter of the law (help) for three versions now - RH6, RH7, and now RH8 - and I give up.

What is the magical mystery proper way of maintaining parent/child .chm links in RH8???

Current issue: Since converting projects to RH8, when searching in Help the "Location" display for results reverted to older project names - e.g. "Product08" instead of just "Product", or "Installing Product" instead of "Product Install". I finally tracked this down to the Project Settings, which apparently retains the original name of the project file even after the actual project files and .chms were renamed.

The issue is that after updating these settings, recompiling the child projects and then the parent project, the changes are not showing up, and it seems like 4-5 times a year I have to fight RoboHelp to properly show children projects - I'm constantly encountering missing links, failure to display updated content, doubled search results, empty Index files, etc etc etc. Always seemingly triggered by one simple change here or there, without rhyme or reason. I have followed the RH help file instructions for four years now, and I give up pretending that the current system is working on our end.

So, please, someone, in a dumbed down spelled out Idiots Guide for Dummy Tech Writers for RH8, step by excruciating step, how in the (world) do I maintain such links whenever I make a change in a child .chm? Based on earlier advice, our parent child is pretty much barebones and serves mostly as a shell with links to the children, where all the actual content is held. IE our parent rarely needs updating to its own content, usually once a year for the copyright notice we put on the main title page.

This topic has been closed for replies.

2 replies

A
Community Expert
AmebrCommunity Expert
Community Expert
April 1, 2011

One thing we found that help was to ensure that no chm files exist in any of the projects. The main problem is the parent, as RH insists on adding the child chm files to the project, when this is unnecessary. We just delete the chm files and live with the "missing topic" icon in the baggage files - a few hoops need to be jumped through (mostly to do with source control) if you need to change these files, but luckily this is a rare occurrence for us.

We compile into a folder within our project structure called "Output" so that is the only chm we expect to find within each project. Peter's site recommends compiling outside the project structure which might help minimise some of these issues.

Additionally, check the [MERGE FILES] section of the parent hhp file.

1. If there are hardcoded paths to each chm, you may need to compile twice using the following steps. i. compile. ii. open the hhp and delete the paths, leaving on the child chm names. iii. re-compile.

Some people report that deleting the paths before the initial compile is enough, but I prefer the double-compile to be safe.

2. Ensure that ONLY the child chm files linked into your TOC are listed. If there are old files that are no longer linked in your TOC, manually delete those entries. Sometimes historical references get left in for some reason.

We include a search test as part of our release process. This will detect doubled search results and hard-coded paths in the hhp file. Just copy the new chm into a folder with the parent and a few other child chms. open the parent and search on a term that is in all/multiple files.

If the path is hardcoded, you'll only get results in one file (the parent).

Usually if we find doubled results (one link will work and one link will show an error page) a re-compile fixes the issue without us making any other changes.  I don't exactly know why this occurs, but it seems to occur if we have extra chm files anywhere in the project folders - RH sort of seems to compile the chms in, even though they aren't actually referenced in the project. Another clue this has happened is the file size will be twice normal.

HTH,

Amber

T
Tech_Writer_KCAuthor
Known Participant
April 5, 2011

We seem to have similar issues in terms of the hardcoded paths in the hhp files. I would love to find out how they get these paths, as we compile all of our CHMs into a single folder (we did this to make it easier for the devs to grab the help files when making CDs or zip files of our software), yet the hard-coded paths are always to what would be the default pathway inside the individual project SSL folders. It just feels like these paths are written somewhere and if I could only find and delete the 'source'....

I've tried deleting the child CHM copies that get stored inside the parent project, but this seems to cause more issues.

A
Anonymous
April 7, 2011

We have just upgraded to RoboHelp 9 from version 7.  We are experiencing the same problems.  We used to be able to edit the HHP [MERGE FILE] section to get rid of the hard-coded paths, but this doesn't work in RoboHelp 9.  The hard-coded paths always come back.  We can't get the projects to merge no matter what.

Any answers yet?

Karen Graf

Peter Grainge
Community Expert
Peter GraingeCommunity Expert
Community Expert
March 31, 2011

I work mostly with merged webhelp and have only looked at merged CHMs from an academic point of view. However, the topics on my site do include a section on merged CHMs with RoboHelp 8.

http://www.grainge.org/pages/authoring/merging_webhelp/merging_method_rh8.htm#mergedchms

Whether or not that will help you identify your problem is another matter.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Use the menu (bottom right) to mark the Best Answer or Highlight particularly useful replies. Found the answer elsewhere? Share it here.
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices