4 Replies Latest reply on May 24, 2006 4:25 AM by MergeThis

    Display TOC Entries & Topics only  for active Software options

      This may not be possible, but thought I would ask since I have spent over 1 day (off and on) searching for fix.

      We have a Software application that has several (currently 5 but will grow) optional Modules, that can be turned on and off when delivered to customer. If possible, I would like to somehow display TOC books and related topics for each module from a SINGLE WebHelp project only when the Software Module is activated.

      I am currently producing multiple outputs from the single RoboHelp HTML project using Conditional Build Tags, but we want to avoid project managers having to choose the correct output for customers with options. So, my dream is to somehow output a complete WebHelp project with all topics, and when opened our Software Application will "determine" what TOC entries are shown.

      I want to avoid having to provide multiple WebHelp project folders with external links or that are opened from multiple Help menu items due to size issues as well as customer perception. Prefer seemless TOC that displays only activated module's documentation with single Help menu access.

      Hoping someone may have had this issue in past and knows standard or workaround solution.

        • 1. Re: Display TOC Entries & Topics only  for active Software options
          MergeThis Level 4
          Your developers will have to do all the heavy lifting on this one. On install, your program would identify the modules being installed and only activate the applicable folders from your complete merged help.

          Good luck,
          • 2. Re: Display TOC Entries & Topics only  for active Software options
            ScottE13 Level 1
            Thanks for your reply. It is good news that this is possible.

            However, it is unclear to me how the folders and topics are activated by the developer and whether these have to be set up individually with something like Map IDs for context sensitive help through which the developers turns things on or off.

            It appears from your response I can produce a single, complete WebHelp project (folder). Then the application must verify activated options and then turn those topics on/off in Help and TOC. So, I guess first question is how do they go about activating folders and if/how are the individual topics within folders handled.

            If there is some resource on web or elsewhere to point me toward, I would appreciate any help there also.

            • 3. Re: Display TOC Entries & Topics only  for active Software options
              RoboWizard Level 4
              Hi ScottE13

              For what it's worth, here is how I would understand it to work. Once upon a time, I was a lone Technical Writer working for a small vertical market software company. The software was sold in modules. Any mix of modules could be purchased. There was a gentleman there that handled maintaining the installation software. So it was his job to determine what to install via the installation software package. In this case, I would supply all the different modules and tell him which module went with which application. Then when the customer installed, only the applicable help modules were installed. There was no magic file that handled turning off or on the availability of the help. It was either present or it wasn't. If it wasn't present, then it didn't apply.

              I'm guessing that this is what Leon meant.

              Hopefully this makes sense... Rick
              • 4. Re: Display TOC Entries & Topics only  for active Software options
                MergeThis Level 4
                what he said...

                Yes, Rick, that's what I meant. But, just in case...

                To make this work, you need to identify which files belong to which modules. The way to do this is either: 1) create a project and place your topic files within folders named by module; or 2) create a project folder for each module and merge them into a single entity (use Peter Grainge's excellent method).

                Then, the developers match the application's module name with the help's module name, and all is well in the land!

                Good luck,