This content has been marked as final. Show 8 replies
Are you using the webhelp pro layout and publishing the output to the RoboHelp Server (or RoboEngine)? If so, I don't really have an answer.
If you are using the Webhelp layout, double click click on the layout, in screen 2 (Webhelp navigation) make sure the option "Synchronize TOC" is activated and the sub-option 'Automatically' is selected. That should solve the pb.
We are using the Robohelp Pro layout, but not publishing to Robohelp server. We have been trying different variations of the "synchronize TOC" option (auto & manual) to no avail. Any other suggestions? I may be able to provide a sample of our project if that would help anyone.
We are not using roboengine, as there is only one of us (the royal "we") that is editing anything in the system at any time.... I do not know where roboengine would play into the problem we are having from my initial post. Maybe if you were to see an example of what I am trying to describe, you may have a better understanding. I could definately set up a demo to show you, and maybe that would help better describe the issue we are facing, than I can do via text in this forum.
Our hlp system is built. We have content and it is synced to our .net application via context ID's. If you are using the "search for someone" screen in the app. and click the "help" button, the information regarding how to "search for someone" shows up in the help system for that screen. The issue we are seeing is that WHERE that information is located in the Table of Contents, is not being displayed. The help system displays the topic that covers the application screen, but does not reflect the topic's location in the TOC, all books chapters, etc are "closed."
I do not know of a better way to convey that and I apologize if I am not being descriptive enough. I read the article you linked, and even browsed numerous other sections. This may be due to the fact that I am relatively new to this whole Robohelp system/publishing/creating etc, but I could not find relevance in your article to my original problem.
Thanks for your help and patience thus-far.
Two red flags pop up for me.
First; "We are using the Robohelp Pro layout, but not publishing to Robohelp server."
You should first follow Rick's topic on this subject.
Second: "Our hlp system is built."
You are generating WebHelp, are you not, and "hlp" is just a typo?
yes I apologize, "hlp" was a typo. It should read as "help."
I did follow the article, but again I do not see where that plays a part for us in particular. While it is the ideal way to run the robohelp system, I do not necessarily think that it applies in our situation. Certainly there are exceptions to the "rule," correct? Is there not a more straightforward answer for my originial question, than the now repetitive "roboengine" answer? I apologize if I sound trite, but I am getting the feeling that my point is getting miscontrued or lost.
This is what we want you to see when you pull up the help system (from any given page within the application) in our situation:
This is what you will currently see when you pull up the help system (from any given page within the application) in our situation:
These screenshots reflect one particular page I used to show the example. So you can see in the screenshots, that the help system is pulling up the appropriate page related to the content in the application. It is just not reflecting that page's location in the TOC. I feel inclined to also mention that our context ID's are set up properly. On the application side, the context ID's that the help system looks for in our application pages, are hardcoded into the application. Maybe this is why we are not using roboengine. Whatever reason we have for doing this, it is ours and that is what we are doing currently "like it or leave it."
If the "roboengine" answer is the solution for our problem, then I would greatly appreciate it if you could quote where in Rick's article it addresses the issue I am facing currently as described above as well is in my screenshots. I have read through the article, but nothing is jumping out at me, as to a solution for the current issue.
Thanks again for your time and patience.
Sadly, my company's Internet police are blocking imageshack. Can one of our colleagues look there and suggest something?
Rick's article says,
The fact of the matter is that WebHelp Pro is an entirely different output type and is intended for an entirely different purpose. With WebHelp Pro output, you need to have a web server running IIS and have a component known as the RoboEngine installed.
At the end he says it may not matter, because the output html is essentially the same, and extra features will be ignored.
Be that as it may, would you kindly generate a test using WebHelp, rather than WebHelp Pro, in case it does matter for this seemingly unrelated issue?
By the way, are any of the books in the TOC linked to a topic? Search the forums for some interesting reading. RH 7 works better than X5.x.x.
Also, if you haven't been to Peter Grainge's site, try here:
See Snippet 1.