This content has been marked as final. Show 5 replies
Originally posted by: tripwire45
I (finally) have a documentation review meeting scheduled for Monday with the "powers-that-be" to avoid future surprises like this and to nail down management's plans and expectations for documentation, so I can actually plan my help file structure ahead of time and before actually creating the initial structure. :sigh:
Ahh! The Holy Grail. Good luck.
Seriously, I've never had nested projects with a lot of book levels purely because as a user I'd soon get fed up with drilling down and go elsewhere. That said, I appreciate that it may be necessary here. If it is, you can easily test to see if there is a limit. I've never come across one or remember anyone posting about one here.
To add to the comments above, you are aware that if Project B needs to be a nested and standalone project that you will end up with multiple copies of the CHMs that make up that project. It's not a problem provides everything is updated after a compile. You could handle this but duplicating your HTML Help single source layout to output to a different location and use the Batch Generate function to compile both Microsoft HTML Help outputs at the same time.
I don't think I'm going to have much of a choice, but I can certainly mention the technical aspects of doing this in RoboHelp during the documentation review meeting on Monday. I may not be offered much of a choice, though so pursuing the "holy grail" my be a forced option (though frankly, the only "holy grail" I'm really fond of is the "Monty Python" version). ;-)
I believe I did set up such an experiment with webhelp. is that what we are talking about here? Helps to know.
I have a feeling that the index and search did not work properly, if indeed it worked at all.
What you need to do is abandon your real projects and set up a test scenario, replicating the structure you need. In each project have just a few words of text unique to that project. That way you know what you are really looking at and what the search is and is not finding.
Before you start, book yourself into a rest home while you are still capable of doing that.
Originally posted by: Peter GraingeBefore you start, book yourself into a rest home while you are still capable of doing that.
LOL. It may come to that. I guess I could spend today and tomorrow creating a relatively complex structure of help projects and see what flies and what doesn't. We are talking about CHM files rather than WebHelp so it probably makes a difference. If I create this thing and it doesn't work, I'll have a good excuse to tell "the-powers-that-be" that it can't be done...at least in RoboHelp.
Ok, I can make it work, but it's kind of "cloogie". I used on test project I used to test basic merging (one master and three subprojects) then created a separate project with one master, four subprojects and one subsubproject merged into a subproject.
I got "Test2" to work but in order to get a nested subsubproject to show up in the master's TOC, I had to copy the subsubproject's CHM into the master's !SSL! folder manually, then create the usual merge project links in the TOC.
To get Test2 to merge into Test1 took that basic concept and expanded on it. I first had to copy the entire directory structure containing all of the Test2 master and subproject files into the folder containing all of the Test1 subproject folders. Then I had to manually copy all of the CHM files from Test2 directly into the the master Test1's !SSL! folder, then add just the Test2 master as a merged project link in the Test! master's TOC (yeah, it's complicated to try and explain).
Bottom line is when you finally compile the main master, everything appears in the TOC and you get a sufficiently involved set of books, subbooks and subsubbooks mapping to the right pattern of nesting. I haven't done anything beyond the basics so there's no indexes, browse sequences and so on, but I could add all that and test again. If this keeps up, I'll end up writing my own RoboHTML help files.