I have a parent project and about 40 child projects. I created seven conditional build tags, and applied them to the various child project folders in the parent project's TOC, based on the categories they should display under.
Then, I went to the parent project's Single Source Layout and defined those categories in so that only certain child projects would display when you selected an item from the Category dropdown.
I followed the steps in my Robohelp user guide book, and double checked with Adobe help, but must have done something wrong or missed a step. The tags are blocking EVERYTHING except for the folders that have no tags applied. I have double checked, and each tag displays the appropriate other tags that should NOTdisplay, but excludes the one tag that SHOULD display. For instance, the tag I highlighed under Content Categories is "Compliance." If you can read the image, the Conditional Build Expression field contains "NOT (everything else)," but does not have "Compliance" in it. The instructions tell me that the Compliance folder (a child project) should display, but it doesn't.
Furthermore, when you pull up the project it displays with an empty TOC, and you have to wait about two full minutes for it to load. You then have to wait an additional two minutes each time you select a category from the dropdown. When I had no conditional tags or category dropdown, everything loaded just fine.
Why is it a) not working and b) hanging up when I display the project?
Thanks!
13
Replies
Hi there
Okay, first impression here is what a mess! I mean no disrespect, but it's a struggle for many folks to simply wrap their minds around Conditional Build Tags. But you have taken it to a level I've not seen before. You are trying to combine Conditional Build Tags in a Parent project to make them somehow work in Child projects? Then you add the extra layer of the Content Categories. I have to say that I'm really not the least surprised that you are having issues.
So first things first. Hopefully you understand that Conditional Tags are really intended for one project. I'm not sure you could even make them work by simply manipulating items in a parent and having them influence child projects. Additionally, even though I'm well aware it's possible to do, I will typically steer folks AWAY from using Conditional Tags to manipulate the Table of Contents. Personally, I've never seen anything but trouble arise from attempting to tag TOC items. So I avoid it like the plague.
Now for Content Categories. Hopefully you realize that when you create Content Categories, you are essentially creating multiple versions of a WebHelp layout. So perhaps your WebHelp without Content Categories in the picture has 4,000 files involved. The moment you introduce the second category, you have essentially doubled the number of output files. Now if you have 40 sets of WebHelp files (You did say you had 40 child projects, no?) you are creating as many copies of the child sets of output files as you have Content Categories. That very likely accounts for the delay in load times.
Personally, I would likely avoid mixing Content Categories and Merged Projects. For the reasons you are posting these issues!
And yes, even though I know RoboHelp allows you to do it and it *SHOULD* work in theory, that's an entirely different matter than having it work reliably in the real world. For example, the speedometer in my truck is marked all the way up to 120 MPH. But I'd never in a million years consider that I should see if it really will go that fast!
Cheers... Rick 
Hello again
Let's talk Multiple TOCs. Let's further assume that you have the content from all 40 projects merged into a single large project.
You then create a different TOC for each of the scenarios.
In your example, you might have a TOC for Marketing. Another for Retail Field and one for Retail Sales, etc.
When you configure your Content Categories, you would create a category for each of the TOCs and in that category, you would assign the appropriate TOC. So after you generate, your end user would simply click the drop-down and choose the category that suits their need and the TOC, Search scope, Index and whatnot would only relate to that area.
Does that make better sense?
Cheers... Rick
The parent project should only contain markers for the child projects, not TOC items themselves.
You say the parent project has folders for each merged project. Do you mean under mergedProjects in the output? If yes, I understand. If no, then where are these folders?
Executives sometimes ask for something in ignorance of what it would require and they then need to be educated.
Your goal is is one deliverable where users will be presented with the ALL category but can then choose their category. Correct?
Personally I would give each department two URLs. One for the full output, one for their department.
I'll take another look in the morning but right now it feels like the management of what is required will not be cost effective.
Each child should appear as a book in the help. Why can't users just select their child rather than picking from a dropdown.
See www.grainge.org for RoboHelp and Authoring tips
Looking at this again the first point has been covered by Rick, excluding a TOC entry does not exclude the underlying topics from the build. They are still there and can be accessed via links and searching.
It's difficult to comment more without knowing how you are building your TOC. If you follow the method on my site, which Adobe now link their help to because it works so well, the parent TOC has no entries of its own other than the references to the child projects and they should never have tags applied. You may already have TOC entries in the parent and provided they are only to topics in the parent, that's OK. Then in order you will have the placeholders for the child projects. You should not have TOC entries in the parent direct to the children. That's not how merging works.
I also need the clarification as to what folders are in your parent and where, source or output.
Finally for now, do read http://www.grainge.org/pages/authoring/merging_webhelp/merging_method_rh9.htm#ducc which covers merged help with content categories. With 40 child projects, it is going to be a nightmare. There is a download there showing how content categories work with merged help. Download that rather than work on such a huge setup. It will enable you to see things more clearly. Right now I suspect you cannot see the wood for the trees.
See www.grainge.org for RoboHelp and Authoring tips
The folders contain each merged link, as they're supposed to. The only file in the parent project is the Recent Updates topic, with the company logo - the "Welcome" page. Everything else is either a merged project, or a link to a topic in the "General Topics" project, such as "Building Hours."
Again, I am not going to combine them into one huge project them because it would be impossible - as I recall from past experience (it happened to me), a Robohelp project can only handle 2 gigs of content before it fails to generate and crashes the software, and many of these child projects contain large PDFs. It's only going to get worse because I'm now posting videos as well. Child projects are just more efficient to manage anyway. I can upload each one individually in one or two minutes as I update them, so the project is always to-the-minute current, instead of waiting hours for the whole thing to publish to the live server all at once. And I can create a department-specific PDF file or .chm on demand in less than three minutes (Click-done), without sorting through thousands and thousands of topics to manually piece it together.
Peter, if it's a nightmare I'm not going to go there. I'll think it through, and see if I come up with something. If I do, I'll let you know. Thanks.
For clarification if and when we come back to this thread, what you are referring as folders are books in the TOC.
Good luck sorting it out. Hope the demo helps.
See www.grainge.org for RoboHelp and Authoring tips
Several years ago Phil Wells needed to have multiple parent projects. His process is described at http://www.grainge.org/pages/authoring/merging_webhelp/merging_method_x3_rh6.htm#multiples. Whilst it is an old version of Rh, the method should still work.
It may be what you have done, sorry but busy so cannot look at the detail of what you have done and what Phil did.
See www.grainge.org for RoboHelp and Authoring tips
AdChoices