This content has been marked as final. Show 3 replies
Some more info re: the versions used to create our old help system:
RoboHelp 3 and 4
Q: 1) how robohelp actually creates the output files
A: Magic :-)
Q: 2) where source and output files are stored
A: Source files are stored in the project folder you have selected. You can generate and publish output files wherever you choose (the default is under !SSL, but most folks don't use that). The source project folder contains many files (htm, js, apj, ali, css, etc.) which it uses for its multiple purposes. Few of those files, except for the htm files, are carried over to the output; however, RH creates three "wh" folders to contain all the TOC, Index, and Search data.
Q: 3) what command line tools convert source to output
We went through this same developer-centric thinking here, and after months of haggling, we finally came to an agreement (probably only because the developers didn't want to do the work necessary to "build" their own output, such as customizing some third-party macro utility).
The problem seems to be that engineers insist that the help MUST be built whenever the application is built. The flaw in this thinking is that the help is not an integral module of the application; it is a peripheral item. That is, if you generated and published your Webhelp last Thursday and they want to build the app again today, how will their app be any different with a four-day-old help version than with a one-hour-old version? It will not, period.
Anyway, good luck fighting the fight,
As Leon pointed out, the developers are probably trying to ensure that they have the latest version of help when they do a build.
When you're working with webhelp, you have three folders: your source, your generated output, and your published output. Your \source is obvious; the \generated output is just that, the output generated when you interactively tell RH to generate your help system, and the \published is where you'll copy the files for distribution (e.g. a server...see the "Republish All" options on the generate output dialog for options there). You can generate without publishing...e.g., to test out the help without 'releasing' it.
I have to disagree with Leon (sorry!) on one philosophical point: you have to think of yourself as any other developer in this system, not as peripheral. Suppose you generate help on Friday. Your devo team adds some features on Mon & Tues. They can do a build and include the contents of Friday's \publish directory. It'll include that version, but won't show any help for the new features (because you won't have written it yet). So that's what your developers need to understand. As long as you can guarantee them a directory where they can always grab the latest help, they'll probably be happy.
Ensuring that the latest version covers new features will require some human communication (!)...but that's true for straight devo, too. You can do a successful build with an out of date version of a library and think everything is OK!
1) During development, make a new local /publish directory that includes a build date in the name. That way developers know when the output was generated. Something like "/publish-05-20-2006" or the like.
2) If they're insistent, I suppose you could do as Leon mentioned, research external macro programs that had a command line component to start robohelp and generate the files...but that seems silly, since you could be working on the source files while they're trying to build. Which in turn means you'd have to start using version control. And if you'd cut a version, you'd have also generated most recent output!
I think if you can simply guarantee them where the latest output files will be, they'll be happy.