Merged WebHelp - Multiple Outputs

 

 

What's covered?

Typically a merged webhelp setup will have one parent and a number of children. All of these will be generated to one output folder. For some installations, the parent and all the children will be delivered, for others the parent and some of the children will be delivered.

It is usually as simple as that but It could be a different combination of children for different installations and if there are many children, it could get tricky remembering all the combinations. It may also be further complicated by some of the installations needing different versions of a child project.

This was the scenario that faced Phil Wells. With around 150 child projects, you can imagine his nightmares. Phil's neat solution was to share the job between many parents! Here is how it works.

Multiple Outputs

Let's take an example. Parent 1 uses say three of four children but needs two variants of say child four.

  1. In Parent 1 create two webhelp outputs called Version 1 and Version 2. Their target folders are Outputs | Parent 1 | Version 1 and Outputs | Parent 1 | Version 2.
  2. After generation, both Outputs | Parent 1 | Version 1 and Outputs | Parent 1 | Version 2 will have a sub folder for say Child 1, Child 2 and Child 4.
  3. Now go to Child 1 and create an output called WebHelp Version 1 and another called WebhHelp Version 2. The only differences between them will be that they point to different targets, obviously, and that they use different build expressions.
  4. The two targets will then contain the required outputs, in this case all the same children but two variants of child 4.

This requires some careful thinking during the setup but once that is done, it becomes plain sailing. The parents shoud rarely change using this method as the children are likely to remain constant. What does change is the content of the child projects. When Phil makes a change, he simply generates all the webhelp outputs and knows for sure that all the output combinations in his Outputs folder are up to date. Alternatively he can make changes to the children over time and then just run through all the outputs. What he does not have to do is enter the error prone area of what output requires what combination of child projects and variants thereof.

Another reason that Phil did this was to enable him to create webhelp and CHM help from the same source. The links are written differently for these two outputs so for every link, you have to write it in the format the webhelp requires and the format that CHM requires and then apply conditional tags to each. Phil then targetted those outputs to suitably named folders within Outputs. With the CHM output, you do not want the redirect described above. In this parent, you create a Welcome page and keep the content minimal.

Demo

I have created a demo of this. Click here to download. The demo was written in RoboHelp 9 and can be upgraded to later versions.

Donations

If you find the information and tutorials on my site save you time figuring it out for yourself and help improve what you produce, please consider making a small donation.

Topic Revisions

Date

Changes to this page

08 Feb 2017

Topic reviewed. No changes made.

18 Apr 2013

Link to demo project added.

20 Jun 2009

Originally part of the RoboHelp 7 article, these instructions have now been separated in this article.