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?
Helpful and Handy Links
We had a problem recently with Visual studio source control and RH just recently
The project in source control was:
In the xpj the path was one level up:
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.
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.
Once you have established the destination path (...\home\interspecweb.htm), the Default Topic is implied as being in the same folder. However, I don't see the Contents.htm file in the Win Explorer screenshot.
- Start Page: The output file that RH creates, which contains the tri-pane frameset and the browser configurations. This file does not appear in the source project folder.
- Default Topic. The source file that you create, which will be the opening page displayed by the browser when you launch the Start Page. This file must appear in the source project folder.
I'm seeing an HTML folder twice in your SSL recipe dialog. Once in the destination path to the WebHelp start page and again in the path for the default topic.
To be honest, I was curious about the HTML folder because it is something you had to have created yourself. Although RoboHelp will show you a folder with HTML in the folder name, it's really not a folder. More of a filter to list files of the .HTM file type.
What you have will need some sorting. It would appear you (or someone) elected to deviate from the default location RoboHelp suggests. And therein lies the possible issue. When folks do that, unless they know exactly what they are doing and why they are doing it, there are certain risks involved. You sometimes end up with file structures that may seem a bit disjointed.
I think I'd start by defining a new Single Source Layout and specifying a completely different location for the WebHelp to end up. Here's a shocking suggestion. Try to re-create what RoboHelp would have suggested. That will be something like this:
Then generate that layout and analyze what you get.
Cheers and best of luck to you in sorting it out! Rick
Helpful and Handy Links
Both the start page and the default topic are located in the html folder, that RoboHelp re-creates (including these two topics).
Well, i can not imagine what happened here, but even if i do chose a different path, in a new folder, when i re-open the project and generate the output, again it re-created all the .htm files, regardless of the path. I do not realize what I am missing here..
Oh, and thank you both for your answers!!
I have no idea how you were able to get that folder into the Default Topic field, but let's try this.
Close the project, open the project's WebHelp.ssl file (in Notepad), and find this line:
<element name="SSDefaultTopic" value="html\Contents.htm" />
Remove the folder from that line, as shown here:
<element name="SSDefaultTopic" value="Contents.htm" />
Save the file. In Win Explorer, delete that entire \html\ folder. Reopen the RH project. The field should read properly, now, and should generate properly.
I've done what you advised:
I also tried to change the path of the Start Page, but if I go up a folder, I get the following error message:
No matter which other folder I select to be the output folder, it will again contain a new html folder (along with new resource folder, image folder, whdata folder, whgdata folder, whxdata folder).
Also, since I changed the path for the Default Topic (removed the "html/"), the Contents.htm is no longer the default topic. It just opens a different topic.
I am getting more and more confused here, I do not know what i'm doing wrong.
Nevertheless, thank you for trying to help me!!!
1 person found this helpful
The second dialog is telling you point blank that you are trying to generate your output into the source folders. Try this.
Create a folder called something like C:\MyWebHelp
In the first field of the first dialog you show, enter or browse to that path.
That will make sure your output is outside your project.
I think you should get a developer to look at this with you to tidy things up.
See www.grainge.org for RoboHelp and Authoring tips
thank you for all your help! It seems, that no matter what I try, the same thing happens... I will ask one of the developers to help me...
I will post the solution to the problem, if I can sort it out!
Have a great day!
As I have no help for now, I am still struggeling with the issue. It seems, that even if I create a new fodler, outside the project, that folder will again contain a html folder with all the htm files of the project. Is this normal? To have all the htm topics twice?
These htm files will then be private files in clearcase and therefore not visible when I make the delivery to the common intergated view.
I am getting really confused, maybe I am looking at this the wrong way?
Thank you again!!
1. Does the html folder appear in Robohelp in the Project Manager pod? If so, you have source files in that folder which means its in the project. This could cause the problem you are seeing with not being able to get rid of the html folder and having it duplicate files. Generating into this folder is also a very bad idea.
2. Possibly some problems are being caused by ClearCase and unfortunately I can't help with it. If it's source control and you can check in/out, try manually checking out the entire project, then changing where you are generating to.
3. Another option is to try a copy of the project that is not in souce control, to see if you can fix it. This works with Visual Source Safe and Team Foundation Server but you might need to check that clearcase doesn't do any special 'watching' or have special files that will force everything into sourcecontrol (as I said, I don't know anything about ClearCase so I'm not sure exactly what it's capable of):
1. Copy your Robohelp project from its normal spot on your C drive, to another location like C:\TestProject.
2. Open the .xpj file in a text editor - Notepad is fine.
3. Delete everything between the <miscproperties> tags and Save.
4. Delete the cpd file.
5. Open the robohelp project and try to change the output directory.
1. Yes, the html folder does appear in the Project Manager pod () and contains all the topics. But, even if I generate in a different folder, that folder will then contain a totally new html folder along with all the topics inside.
2. I believe it is not a ClearCase issue, as it is the same scenario even when I copy, work and generate the webhelp locally, outside of ClearCase.
3. I opened the .xpj file with a text editor, but I only found one instance of the <miscproperties> tags, so I could not delete anything.
It is a big mess, right?
Anyway, I cannot thank you enough for trying to sort this out with me!
I have looked at a project Zita sent me and there is no duplication.
What is happening is there are source files and output files.
The source is what you work on and the output is what you generate. If you look at the HTML inside the files, you will see it is different.
If you apply a build tag to some content for example, the text will be in the source file but it will not be in the output file as RoboHelp will not have included that content, assuming your build expression excluded the tag.
See www.grainge.org for RoboHelp and Authoring tips
So, the htm files in the original html folder are the source files, and the htm files in the second html folder (within the first html folder) are the generated output? The, should I just add that to Clearcase? Will these (the output) be replaced when I, on another occasion, modify the source files and re-generate the output?
Output files should never be in a source control environment. All the more reason to never Generate output in a folder under the source project folder. The output should be completely outside the source folder. A Version 8.2.2 XYZ help would ideally live in these folders:
- C:\822_xyz_project(or _source, or whatever)
- C:\822_xyz_generate(or _output, or whatever)
I certainly don't mean to be arbitrarily disagreeable, but here's another viewpoint to consider.
Personally, I'm not sure I'd ever say that output files should never be in a source control system. (And yes, I do believe I totally understand the difference between the two. )
Sometimes a workflow and environment is actually structured in a manner where that particular setup is actually beneficial and desired by the development team. For example, if you are creating a help system used by an application, the developers of the application may actually benefit tremendously by having the output file(s) in the source control system. This is because even though the files are output from your perspective, they are considered source files from the developers perspective. So having the output file(s) in source control would make total logical sense as the developers would use your output file(s) in the final or intermediate builds of the application installer.
As long as the RoboHelp author understands the difference between the source and output folders, there really shouldn't be any reason that the output folder can't exist as a sub folder of the source. After all, that's really the way that RoboHelp works until the help author elects to place the output files elsewhere. Unfortunately, that's exactly when we see help authors get themselves into trouble. When they start rearranging where the output files go without understanding the real differences between those and the source files. Because of this, I would recommend that anyone choosing to relocate the output folder tread very carefully. Unless you have good reasons for doing so (and I know some folks do), my vote is to leave them in the default location of !SSL!\Output Folder.
Helpful and Handy Links
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
1 person found this helpful
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!
Hello all and thank you for all of your replies!!!
What I decided to do is just create an Ouptut folder and add it to source control (so that the developers can access all the updates I make). This Output folder will now contain the html fodler, which will contain the output htm files. This is the simplest solution I could find. I hope there will be no problems!
Thank you again and good luck!