Publishing has been cancelled

[bbleft]

I have created a merged WebHelp project. I already generated the master project and published the subproject once and everytig went fine. After reviews, I imported a stylesheet and then began running into problems. Some of the topics went missing (a red "x" to the left of the topics). A 'book folder' was created for the "lost" topics. I used IE to drag the help topic from each .book folder back to the Help project folder. Were the topics lost because I clicked the Apply button after I imported the stylesheet into the Help project?

It also seems like all the files in the subproject have been set to read only. Did that happen because I generated and then published the subproject?

When I finished making the topic updates, I successfully generated the project, but was unable to successfully publish the supbroject again. The message displayed said: Publishing has been cancelled. Access denied. I did not cancel the publish.

The first publish was to a folder on the hard drive using the File System connection protocol. By using a different folder, I was able to successfully republish to the new folder. However, publishing to the original folder was cancelled. Now I have two folders, but I suspect that only the new folder has the latest information in it. Can I delete the old folder? Is it better to copy the new folder content into the old folder and delete the new folder?

There seem to be some sequence protocol that I violated here. Only import a stylesheet and not apply it? Only publish a subproject once?

How can I get RoboHelp to publish more than one time to the same folder? Could I delete the content in the destination path before republishing?

Not knowing what RoboHelp is doing when I click on a button puts me at a definite disadvantage.

Thank you.

[RoboWizard]

Hi bbleft

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

[bbleft]

Rick,

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?

Thanks,
Jim

[Peter Grainge]

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.

[RoboWizard]

(In my best Homer Simpson voice) Doh!

Thanks for the follow up my friend. Somehow I totally managed to space off the subject line of the thread!

Guess it's time to up my meds again... Rick

[Peter Grainge]

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.

[bbleft]

Peter,

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.

Thank you,
Jim

[Peter Grainge]

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.

[bbleft]

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.

Thanks again,
Jim