Skip to main content
October 28, 2010
Question

Robohelp 8 generates html folder within the html folder

  • October 28, 2010
  • 2 replies
  • 3233 views

Hello all,

I am having some issues generating the webhelp from Robohelp8. After I change something in the project (which is stored and checked out in clearcase) and re-generate the output, it automatically creates a new html folder within the original html folder and re-creates all the existing htm files, which make up the project. And then the start page searches and takes the files from the second html folder (within the first html folder). I tried adjusting the path, but it doesn't help. Any ideas why this happens?

Thank you!!

Regards,

Zita

This topic has been closed for replies.

2 replies

Community Expert
October 28, 2010

We had a problem recently with Visual studio source control and RH just recently

The project in source control was:

$/Documentation/Product1/main

In the xpj the path was one level up:

$/Documentation/Product1

So the guy thought he was working in the 'main' folder, but when he checked in/out, RH would add/get from the Product1 folder instead. So we had duplicated content in both places.

You could see if you have a mismatch there by opening the xpj in Notepad.

Amebr

Captiv8r
Legend
October 28, 2010

Hi there

Out of curiosity, you *ARE* generating WebHelp, right?

Can you please post a screen capture of your Windows Explorer showing the project folder structure as well as the first screen of the Single Source Layouts dialog for WebHelp?

Cheers... Rick

Helpful and Handy Links

RoboHelp Wish Form/Bug Reporting Form

Begin learning RoboHelp HTML 7 or 8 moments from now - $24.95!

Adobe Certified RoboHelp HTML Training

SorcererStone Blog

RoboHelp eBooks

October 29, 2010

Hi,

Thank you for the quick response. Yes, I am generating a webhelp.

I will attach the screenshots.

On some occasions, when i set the path, it prompts me, that there already is a html folder and i need to chose a new destination. But, within this htm folder are all the htm files which should be overwritten when i generate the new output.

Thank you!

Zita

MergeThis
Inspiring
November 12, 2010

Thanks for the input Rick as I too can see the benefits for some of having output source controlled. Like you I see both sides of the arguement and fully accept that for some this is not the way to go. To add to your application scenario, adding (say) a CHM file to source control at a said location that can be picked up automatically by a build script can add real benefit to all.


  The RoboColum(n)   @robocolumn   Colum McAndrew

Rick, if your documentation output files "are considered source files from the developers perspective," you should be vewy, vewy afwaid of your developers! A doc set is a resource (much like provided web browsers, servers, utilities, libraries, etc.) that is provided along with the software code, not intrinsically a part of it. That is, the developers add the doc within the final build process, but do not include it in the software code build. Of course, your usual single-chm-file output is a whole other thing than our ~2100-topic, 40-project merged WebHelp doc set.

Colum, I don't see the benefit to adding output "to source control at a said location that can be picked up automatically by a build script." Our developers automatically pick up our non-source-controlled output by a build script that targets the output in a network location far, far away from our source-controlled source files.

Even if the doc source control database were to be kept separate from the software code source control database, I can envision problems in how a minor slip in the developers' build script could corrupt the doc source control database. Yeah, I know, that could never happen, right?

In addition, the added output burden in the normal scheduled backups by your IT folks might tend to overload the assigned servers. In the WebHelp project mentioned above:

  • Source files: 13589 files at 401 MB
  • Output files: 15000 files at 209 MB

Adding an extra 50% to the load every day, twice a week, weekly? That can't be worth it. When lost, the output can be easily reproduced from the source, and therefore needs not be controlled at all. Archive final build versions somewhere? Sure! Source control all variations in an ongoing manner? Totally unnecessary!

Good luck,

Leon