Carol, why are you using WebHelp Pro if you aren't using RoboHelp Server? You know the output from that doesn't work well in a basic web browser and is coded specifically to work in conjunction with the RoboHelp Server software, right?
Thanks for your quick reply.
I do know that, and had hoped to move over to WebHelp with the next major release. But they inserted another ‘minor’ release and with the time constraints and the switch to a new computer and to RoboHelp 10 we decided not to risk problems by switching to WebHelp.
In addition, the switch requires some research on my part (for which I don’t currently have time ☹) and might require changes to how the Help is connected to the applications.
All that said, the WebHelp Pro has been working pretty well without RH Server.
LOL, "All that said, the WebHelp Pro has been working pretty well without RH Server."
And yet, here you are asking about resolving an issue, no?
I'm thinking you should serously investigate switching to regular WebHelp. Especially since you are reporting issues with the behavior of the toolbar buttons and behavior of the breadcrumbs.
The reason is that RoboHelp Server manages some of that aspect when you publish content there. So I'm not surprised to see you report inconsistent behavior with the different "modules". I'm guessing this is a "merged" setup?
When I posted, I didn’t know whether it was an issue or simply a matter of user ignorance ☺. I don’t know enough about the differences between WebHelp and WebHelp Pro to identify issue vs. user ignorance at first glance.
As noted, we have talked about switching to WebHelp when we have sufficient time. However, we are also considering whether we should move to RoboHelp Server.
What’s a merged setup? I generate five sets of WebHelp and check them into Source Control, where the application is set up to link to the opening topic for each module.
Okay, so let's forget the fact you are using WebHelp Pro and just look at the main issue you reported in this thread.
You said you click a "Home Button" on the main toolbar?
Is this a button you added? If so, you pointed this button specifically to the Introduction.htm file.
So I might think that in order to be consistent, you would want to point the Home button to the introductory topic for the module, no?
The WebHelp opens in the browser. I click the Home button that is one of six buttons—Contents, Index, Search, Glossary, Print, and Home—that appear above the left pane (which displays the TOC). The buttons are included on the Help toolbar as a result of selections made in the WebHelp Skin Editor. The properties for the Home toolbar item include an Action link to Introduction.htm. This works correctly for the Core Help, whose default topic is also Introduction.htm.
Since the project uses a single skin, I see no way to configure the Home toolbar item to include an Action link to anything other than Introduction.htm. But that’s not the desired behavior for the licensed modules.
The desired behavior is for each Help module to
· Open to the associated default ‘introductory’ topic (each module has a unit introductory topic)
· Open “Introduction.htm” when the user clicks either the Home toolbar item OR the Home link in the breadcrumbs area.
This may not be possible without the creation of multiple skins or windows.
I think what you need to do is edit your skin. Duplicate the "Home" button as many times as you have layouts. Then configure the copies to point to the correct page. Be sure to name the copies to match the layout they will be used with. Close and save the Skin Editor.
Now, in each of the layouts, edit the recipe to only include the desired "Home" button.
That way you should have a single skin and accomplish your goal of having each skin presenting a single "Home" button that points to the correct page.
Good morning, Rick.
Thanks again for the suggestion. However, probably because this is WebHelp Pro, the recipe doesn’t work. In the WebHelp Pro Options dialog box, there is no option for selecting a Home button.
Also, the Home button works as desired from all the modules – clicking the Home button on the Help toolbar always opens Introduction.htm.
I would like the Home link in the breadcrumbs area to open Introduction.htm, too, instead of opening the default ‘introductory’ page for the licensed module (the inconsistent behavior that QA does not like).
I just looked at the HTML for the master page, named “Main” and see the following line for breadcrumbs. I don’t know how RoboHelp maps “home” to a particular page. Perhaps I need a unique master page for each layout, with “home” pointing to Introduction.htm.
<?rh-placeholder type="breadcrumbs" ph-align="0" sep-char=">" home="Home"
Looks like you're back to that initial stumbling block - you need to get off the WebHelp Pro wagon ;>)
You've probably spent more time looking around for answers than it would have taken to flip over to WebHelp (LOL)
Too true, Jeff!
However, I’ve learned a bit more about the innards of RoboHelp skins and breadcrumbs, which is always a good thing. The problem is now crystal clear: the Home link in the breadcrumbs placeholder always points to the default topic for the TOC and cannot be changed to point to some other page. Each of my five SSLs points to a unique TOC which points to a unique default page.
As soon as we get this release out, I need to research what impact moving to WebHelp might have on how the application calls the Help modules and the few context-sensitive Help topics.
1 person found this helpful
Shouldn't make any difference at all - CSH works the same way in both flavours AFAIK
1 person found this helpful
LOL, that's true, Jeff! Only if RoboHelp Server were being (actually) used would the calls be different because I believe one has to specifially call topics a certain way. (I think)
Back to my hidey hole... Rick
Colum can probably confirm/deny our assumptions on this one ;>)