I currently generate a JavaHelp helpset from a FrameMaker book using my own utility, written in Java, where I have total control over all XML, map, and .hs files used in the helpset. My helpset is displayed in the JavaHelp viewer with TOC items collapsed. I set this level of collapse when I write the TOC XML that JavaHelp uses to construct the viewer's TOC pane, by setting the expand attribute for each tocitem to false, as in .
I'm now interested in shifting to a more standardized help generator and have begun experimenting with RoboHelp. I am able to generate the helpset, but I cannot find a way to collapse the TOC items in the final output. When I view the results in the JavaHelp viewer every heading in the entire TOC is expanded.
How do I set the expand attribute in RoboHelp's JavaHelp layout?
If you are insistent upon the output being JavaHelp, I'm going to officially say that you are likely better off using your own utility. RoboHelp will likely be a source of nothing but frustration for you if you want to use it to create JavaHelp. Almost nobody is creating JavaHelp so Adobe really has no real incentive to improve RoboHelp's ability to produce it.
If you are interested in using RoboHelp as your editor, I'd say it might be useful there. But once you create the content, I'd suggest closing RoboHelp and using your home grown utility to generate, since it already does what you want.
Sorry, but dem's the breaks... Rick
Helpful and Handy Links
I'm pretty much locked in to JavaHelp, at least for the near term, for context sensitive online help in a Java client/server app, where Java is the lingua franca, and where development cycles are allocated to frying bigger fish than the Help infrastructure. Still, I might be able to get traction with the "JavaHelp support is minimal in most of the industry" lament. Thanks for your advice.
I still like the idea of using RoboHelp, it seems like a convenient way to smooth some rough edges present in my home grown approach.
But it looks like it won't be a clean break. I may be able to extract the benefits offered by RoboHelp and then do some post-processing of the output, although that still makes us dependent on code that only I understand. I was hoping to get something more universal.
I've been using RoboHelp to generate JavaHelp for a few years, and it worked fine--until I upgraded to RoboHelp 10! Now it can't find java.exe, javaw.exe, and jar.exe. I point RoboHelp to the JDK install folder in its JavaHelp Option dialog box, I've updated the PATH enviroment variable to include C:\Program Files\Java\jdk1.7.0_05\bin (for java.exe, javaw.exe, and jar.exe) and C:\jh2.0\demos\bin (for the hsviewer.jar), and created the JHHOME and JAVA_HOME variables. But no go. That was all I needed to do in RoboHelp 7 and 8 for it to work. (Even though Rick says, "Almost nobody is creating JavaHelp," every software company I've worked for "needs" JavaHelp for their products. :-< I've convinced them to go to WebHelp for all but one product, which is a server product that can be installed on Unix and Linux. They don't want to make a browser part of the system requirements.)
Where in the RoboHelp HTML files is the path to the JDK stored? I am pointing RoboHelp to the location of the java.exe, javaw.exe, and jar.exe files, but it doesn't "take" or something. I want to look at the RoboHelp files to verify that it is specified correctly.
Good luck with this. I think you will find you need one of the Adobe developers to answer this question. Likely only they will know where exactly that information needs to be tweaked to make RoboHelp work.
How many software companies have you worked for?
Helpful and Handy Links
I'm currently using RoboHelp 9, not 10, to generate my online_help.jar.
I have not told RoboHelp anything about Java on my system, and it works.
The only thing I had to do was choose between JavaHelp 1.1.3 and 2.0, in the layout properties panel (right click on the JavaHelp layout in the Single Source Layouts pod).
There are limitations, as noted in my original post in this thread, but the JavaHelp file is created.
BTW, it's pretty clear that JavaHelp is deadend technology, never to see another update. We will bite the bullet and jettison JavaHelp in favor of WebHelp, if not in the release currently in development then the one after.
Woohoo! It's working now. I asked my Java Developer to help figure out why RoboHelp couldn't find javaw.exe, etc. He tried a bunch of different Java Developer magic tricks, but the end result is that certain registry settings are supposed to be updated/created, but apparently weren't. In the following key:
JavaHelpHome = C:\jh2.0
JavaHelpJdkHome = C:\Program Files (x86)\Java\jdk1.7.0_05
JavaHelpJdkVersion = 1.7
(This should really be in the help file!) There are other Java-related settings that didn't have any effect when we changed them. We didn't have to update the environment variables, because Java is "supposed" to do that when it installs. (But we verified that they're there: JHHOME= C:\jh2.0 and JAVA_HOME=C:\Program Files (x86)\Java\jdk1.7.0_05, which is the path to the JDK.
So now I can generate Compressed JavaHelp 2.0 from within JavaHelp without any fancy scripts or typing anything at a command line. Yay!!!
Europe, Middle East and Africa