When doing a command line compile for a project, it is pulling in the wrong index. In our project, we have two indices: One contains an old index that we are reluctant to remove in the event it is needed again, and another (the default index of the project) is a blank index.

When I compile the project through Robohelp, the blank index is pulled in, and there is no index displayed in the final output (chm). There is a tab for the contents, the search, and the glossary. However, when doing this through the command line using the exact same ssl, the index is included and it is pulling in the old index that contains data.

Does anyone know of a way to stop this from occurring other than probably removing the old index?

The <Default> index is selected, and this is the index that is blank and never outputs to the chm when compiled from within Robohelp. But for some reason, it's pulling in the other index that is not the default and is not selected in the SSL dialog.

If I delete the old index, it works correctly. Logically, this doesn't make sense since the SSL file itself (when opened outside of RH in Notepad) shows that the index is set to <Default>.

Peter, I had read your article on your site, but I didn't find anything to help with this problem.

I tried selecting the index I wanted in the output, and it works when compiling once. On the second compile, it does not use that index and instead switches to the index that is historical.

Additionally, I found other problems when doing a command line compile:

The glossary is not loaded into the output chm. In the HHP file, the glossary name is correct before being compiled via command line. Once I compile and check the HHP file again, the glossary name is replaced with the name of the project (e.g. the original glossary was called glos1.glo, but it was replaced by <projectName>.glo, where <projectName> is the name of the project. The output itself does not contain a glossary, as that glossary does not exist.

Additionally, merged chm files in the project are not being merged. The HHP is overwriting the default value--just the file name--I have in it (e.g., <projectName>.chm) and replacing it with the direct file path (e.g. C:\Projects\ProjectName\Output\<mergedFile>.chm). As a result, obviously, the chm does not contain the merged chm information.

Make your index as default index which you want to use in your Output. In the HTML Help Options make sure the index is Default, Then run your commadn prompt as Run as Admin, change the directory to the Robohelp Insatll folder using command cd C:\Program Files\Adobe\Adobe RoboHelp 9\RoboHTML and then run the command.

My apologies for not including the version. I'm using RoboHelp 9.0.2. After the upgrade from 8 to 9, I went through and rebuilt all the TOCs, modified the HHP, and essentially did the steps documented in the PDF you pointed to. The project builds fine from within RoboHelp. There is never an absolute path. It's only when the project is built by command line the path reappears.

I will repeat the steps and see if that cures the problem.

[UPDATE] I completed the steps outlined in your PDF to correct the full file path from being in the HHP. If I build the project within RoboHelp, the merged file is included. But when I did the command line compile, the merged file not included.

[UPDATE again] Sorry, I just thought I would check a few other things. After doing all the steps again in the PDF then doing a command line compile, the HHP file is being updated following the compile to include the absolute path to the chm. Additionally, the merged chm file is being included now, but it is not being included in the browse sequence.

On a side note, is there a way to stop the hhp file from changing the order of the merged files? For example, I have several projects merged into a single master project in alphabetical order. However, when I compile the project in RoboHelp, the file order is modified, which causes the browse sequence to not be in alphabetical order. To fix this, I have a text file that contains the correct order of the merged chm files. I copy and paste it into the hhp file, then recompile again, and it works perfectly. But I always have to compile twice.