Windows 7 64-bit
Ok. I'm trying out the command prompt generation for an HtmlHelp output for the first time.
I followed the RH documentation to the best of my ability and came up with the following:
rhcl "d:\hg\pcdmisqa\pcdlrn\help\vision\PC-DMIS Vision.xpj" -l "Vision Common CHM" -o D:\DocProjects\Outputs\common_chm\
The first parameter launches the project, the second defines the build layout, and the third the output.
It generates a help file. But I have these questions / issues:
1) Is there a log file generated to determine if there were problems in the compilation? If so, where?
2) Is there a way to specify the output chm name? It seems to be basing the name off of the xpj filename instead of getting it from the name defined in the layout. I want the file name to be "pcdmisvision.chm". It's giving me "PC-DMIS Vision.chm". It's not a big deal because I can use other command prompt commands to rename it. But still... it'd be nice.
3) When I launch the generated help I'm getting this strange hh.exe - No Disk error:
Clicking any of the buttons shows the above message again. But after clicking three times, it eventually launches the help:
But it launches with this topic as the default... maybe because it's alphabetically the first? It's certainly not going to the default topic specified in the layout. Plus the Index and Contents tabs are missing. I have the hhc and hhk file defined in the project and specified in the layout. The Search and Favorites tabs are working. The Glossary tab doesn't contain any entries (though it should).
If I generate the exact same layout inside of RH everything is generated as expected and desired: TOC, starting page, no hh.exe error...
Anyone else experiencing similar issues? This funcionality seems very buggy to me.
How can I resolve these issues?
Thanks in advance!
Command line generation is not something I use but Bill Albing wrote an article that is on my site at http://www.grainge.org/pages/authoring/command_line/command_line.htm. Maybe something in that will help.
See www.grainge.org for RoboHelp and Authoring tips
Thanks Peter. I still think there's a bug somewhere in the software. As far as I know I'm doing everything correctly. Or maybe command line generation only functions with 32-bit systems? When I get a moment, I'll try to take a look at that. I did find out how to get the compile log.
There weren't any "errors" per se in the log however. I did have a bucket load of "HHC4001: Warning:" messages that said this:
"The following alias line does not contain an '=' character separating the topic IDs: </alias>"
But aliases have to do with context mapping not with this weird hh.exe message. I doubt that's the culprit.
The index file, PC-DMIS Vision.hhk, for the Index tab is listed in the log.
The content file, PC-DMIS Vision.hhc, for the Contents tab is not listed in the log.
Who knows. I may need to come up with an alternate way of automating.
I did some more testing and have some more information on this. First, I did have RH 7 and RH 9 both installed in my original post.
1) I tested this in a 32-bit Vista machine (VMWare) running RH 9 (same version) with my exact same project. My rhcl command line generation in that environment used the correct filename defined in the layout and it had the contents and index tabs displaying fine, as hoped. It looked great. And No hh.exe errors. Yay!
2) I copied that same chm file onto my 64-bit Windows 7 machine and opened it. Strangly enough, I got the same hh.exe error described in my original post, after three mouse clicks on any of the buttons, the help finally appears.
3) I then changed my code in my batch file on my 64-bit to find and use RH 9's rhcl.exe file specficically by driving down into the RH 9 install directory and running rhcl.exe.
Maybe it was running the rhcl from RH 7 and not from RH 9:
cd /d "c:\Program Files (x86)\Adobe\Adobe RoboHelp 9\RoboHTML\"
rhcl.exe "d:\hg\pcdmisqa\pcdlrn\help\vision\PC-DMIS Vision.xpj" -l "Vision Common CHM" -o "D:\DocProjects\Outputs\common_chm" -g D:\DocProjects\Outputs\common_chm\vision_compilelog.txt
It did generate the file just like the 32-bit Vista machine did. Correct filename, correct TOC and Index and Glossary. Everything functioned, except I still got that cursed hh.exe errror I have to click three times to get past.
When I copied this Windows 7 64-bit generated help down into my 32-bit Vista environement, it functioned normally.
4) I tried uninstalling RH 7 so that I just had RH 9 on my system and re-ran my test on my 64-bit system. Same hh.exe error.
So, something in the 64-bit world is screwing up the display of command-line generated helps. Anyone else on 64-bit machines seeing this? Any ideas on how to fix it?
Message was edited by: JaredHess
Found out some more info on this.
The good news is that this isn't really a problem with command line generation. I originally thought it was because I never noticed the above HH.EXE error message when generating the chm from within RH. It turns out I can see this error with this project regardless of the build method as long as I navigate to the chm and double-click on it from within an Window's explorer. For whatever reason, if I view the compiled help from within RH (by right-clicking on the build layout and choosing View) or from the post compile prompt (which is what I usually did), I don't see the error.
The bad news is that this means this error is project specific and I have no idea what is causing it. A google search on "hh.exe - No Disk" yields very little results.
Wonder if this is it?
Rick Stone recently responded to a post where the user could view the help from RoboHelp, which you can, but not when they opened the file direct. It was on a 64 bit system and Rick pointed out they needed to register the 64 bit version of the HHActiveX.DLL.
Could this also be related to your other problem re merged help?
See www.grainge.org for RoboHelp and Authoring tips
Hmm, if that were the case, I think all my chms I've compiled would have the same hh.exe problem wouldn't they, not just this one? And same with the merged file problem. I would again suspect that all merged helps would have the same issue if that single dll were not registered for whatever reason? Anyway, I'll double-check the registration of that dll just in case. Thanks.
I wanted to report that I fixed this problem a couple of weeks ago. It turned out my xpj file had issues. I had multiple references pointing to merged chms, but to pathways that no longer existed in the <MergedFiles></MergedFiles> element.
Once I deleted these references using a text editor and saved the fixed xpj and recompiled, I no longer got the above error.