This content has been marked as final. Show 8 replies
My own speculation is that you are using RoboHelp 6, no? In that version, there is a pesky and difficult to reproduce bug that will bite you when you work with content that has been imported. What normally happens is that you interact with the Topic Properties dialog in some way. After clicking the OK button to commit the changes, WHAP! You see one or more of the ".Book" messages. And the topics are missing.
So it's nothing you have done wrong or might change. It's a RoboHelp HTML "feature" of version 6. There is, however, a way to minimize or totally avoid this happening. I find that as long as I make changes in other ways that avoid using the Topic Properties dialog in any way, I safely sidestep the issue. So here are some tips.
* If you need to change the Topic Title or the Topic File Name, make the changes over in the Project Manager area on the left. Keep in mind that you may click View > By Topic Title or View > By File Name to list these in different ways.
* If you need to change which style sheet is being used, edit the topic and use the Style Sheet Toolbar Icon to associate the desired style sheet.
Hopefully something here was useful... Rick
Rick has covered the issues you faced but bear in mind Publishing Has Been Cancelled can occur quite independently of those. That particular one is covered in Snippets on my site.
Yes. You are 100% correct. I am using RoboHelp 6 and the topics were imported. I selected all the topics in the project in the right pane with the Topic tab selected. Is following the online Help for "Linking style sheets to multiple topics" is only for beginners?
Any idea why trying to Publish a subproject a second time causes the publishing to be cancelled? Is it because RoboHelp already published to the same folder? I believe I read that leaving the Republish all box unchecked would only publish the files that had changed. Would checking the Republish all box publish all the files? Or would I still get the Publishing has been cancelled message? Or should I just not publish? What does publishing a subproject do anyway? My guess is that it does something inside the master project. Update the TOC? Is there a more reliable way to keep the master project updated?
Does RoboHelp not like merged project folders in the !SSL! folder? Is there a recommended place for a publish folder?
Why publish to the !SSL! folders? Creating merged webhelp involves two processes, generating which has to be done locally, and publishing which is optional and is usually done to a server.
You can publish locally but for most people that would be unnecessary.
I would suggest you generate the parent to a folder you create on your local drive. That creates the mergedProjects folder with a subfolder for each child. Generate the child projects to that.
If you do have a reason for publishing locally as well, do the same to another folder.
There's a topic about merged webhelp on my site that answers your other questions.
Publishing a second time is not the reason.
Thank you for your answers. Snippet 55 allowed RoboHelp to successfully republish the subproject. (I still suspect that publishing the subproject set many of the subproject files to read only.)
The answer to your question (Why publish to the !SSL! folders?) is easy. Ignorance. Following the online Help procedure "Merging WebHelp projects" Step 8 says that generating the master project creates two sub-folders in the project's output folder (default name is WebHelp): mergedProject and subProjectName.
Should I generate the Help master project to a folder outside of the project?
Was my mistake in allowing RoboHelp to create the mergedProject folder inside the !SSL! folder?
I am trying to keep the number of folders to a minimum to allow rapid checkout/check in to Visual SourceSafe.
There's no right or wrong about where you generate. However, as each SSL folder is in one project, you tend to associate it in your mind with that project. In the case of the merged output, that comes from many projects. My thinking therefore is that it is cleaner to have a folder for that purpose outside the individual projects.
Many argue there is not point in checking outputs in and out on the basis you can recreate them. Some prefer to check outputs in as proof of what the created. If you favour the first view and you keep the outputs external of the projects, it's probably clearer as to what needs checking in and out.
Peter and Rick,
Thank you for your answers and for your experience. Following your advice, I was able to recover from the "missing" topics and successfully published the Help project and subproject by ensuring the topics were not read only.