This content has been marked as final. Show 7 replies
I am using RoboHelp 6 and the method continues to work.
Thanks for that Peter - I had visions of having to remake dozens of links if and when I upgrade to RH6.
Bit of a dilemma for Adobe - if they ever sort this bug out they'll have to be careful not to foul up the hundreds of help files that have been produced using your work round.
If they do fix the problem, it should not affect projects set up the way I describe.
At the moment, if you put all the child projects in a folder called mergedProjects (that is, the same as the folder that gets generated by RoboHelp) then the links between parent and child would work in the output. The problem is that in the source the links from parent to child falsely report as broken so that you cannot easily see truly broken links. Thus fixing that really should not break anything.
That said I would still carry on using this method as it does make it much easier to work.
I notice you mentioned having a number of parent projects. I wondered why you do that as one parent should suffice unless it is to get different skins or suchlike. Not sure if you are aware the idea is to generate all the projects and then just deliver what is required. You don't need to keep compiling different configurations.
I have a number of child projects that are common to a number of help files.
For example I havea child project called Windows_Terminology that explains what is meant by frame, radio button, scroll bar, etc. This gets included in every Help File I have. I set up SSL's for Windows_Terminology that generate outputs for Project 1, Project 2, Project 3, etc.
I've found that as long as Windows_Terminology is at the same level in the file hierarchy as all the other child projects, then I can generate to the various 'mergedProject' sub-directories in the different help files and my single copy of Windows_Terminology sufficies for multiple projects.
My file hierarchy is broadly as follows:
Level 1: General type of software.
Level 2: Module within software.
Level 3: Master projects and general folder for child projects. (As per your structure).
Level 4: Child projects.
Level 1 and level 2 are primarily needed for organsation - so that files can be stored in a logical arrangement.
Any child project in level 4 can then be put into any master project in level 3.
As another example I have a child project called Software_Definitions. This contains definitions of the all terminology used in all our software. Outputs are controlled by conditional build tags I can output different varients for the different forms of the software we have.
It means if a software definition is common to several forms of our software I only have to update the definition once and regenerate Software_Definitions. All the appropriate help files then get the updated definition, thus avoiding keeping individual definitions files up to date.
Are you UK based?
Yes. (We've exchanged e-mails before).
If you want a small working example, I can e-mail one to you.
I thought we had. Yes send me something that emulates the overall setup. Screenshots of Windows Explorer would be OK.