RH 2015 Responsive HTML5, Way to Prevent Default Topic From Being Added to All URL's for a Product's Help Buttons?

[KFarrelly]

Help buttons in our product have redirection links associated with them to bring up window-specific topics (html files within the a Responsive HTML5 help output's html folder, stored on our web server). This setup previously worked okay when I was trying out Responsive HTML5 with a trial of RH11. The help button for a window opened up the correct topic based on what we' had associated with the help button in the product via its redirection link. This setup also has worked okay with the WebHelp output we have traditionally used for help output.

We now have RH 2015 and this setup isn't working as desired with a Responsive HTML5 output. The URL's for any topic that help buttons in the product are supposed to open have text appended to them that cause the default topic for the help project to display rather than the intended topic. The 'default topic' being what I've designated in my help project's Responsive HTML5 Settings > Content window as default.

Is there something that can be done in project settings to prevent default topic details from being tacked on in this manner? In this example, the URL I wanted a help button's redirection link to call up is the text in pink. But the text in yellow is being tacked on, which opens the default help topic (see second image), not the topic I want displayed in this case.

[KFarrelly]

Presenting this question in simpler terms to help clarify. Is there a way to NOT to have to specify a default topic within the Responsive HTML5 settings in RH 2015 -- to leave it blank? We don't need a default specified since our help buttons in our product open specific topics. The default setting seems to be interfering with our setup. Or is there a file in the generated output where I can adjust code to remove the default spec? The default doesn't interfere when our output is WebHelp, only when output is Responsive HTML5.

[Captiv8r]

Hi there

As you have seen, all you can do here is to click the Browse button and nominate a different topic to be the default.

I manage my RoboWizard.com site using a Responsive HTML 5 output from RoboHelp. As I click different topics in my TOC, I note that the address presented to me in my browser address bar reflects this:

http://www.robowizard.com/RoboWizard/index.htm#t=Skins%2FFlashHelp%2Famber.htm

So even the basic URL seems to have this "issue" as part of the standard way of operating.

Is it possible to use basic URLs in your context sensitive calls? I know some folks work that way.

You might also want to report your issue to Adobe using the link below.

http://www.adobe.com/go/wish

Cheers... Rick

[KFarrelly]

Thanks for the link to Adobe's wish page.

Can you clarify what's meant by 'basic' URL. Some things in the URL's I set up for the RDI that calls up a topic for a 'help'

are determined by how our IT department and development department need them structured. We have 40 some help buttons in the product, this 40 rdi's each calling up a unique topic from the help. The #html in the help.html#html part of our URL's launches the help in a separate browser window from our product. The help.html is the 'index' page for my project.

What's odd/frustrating here is that I tested this with output from an RH 11 trial (early last year I think). The output/setup worked ok then, calling up the desired specified topics. It seems like something has changed since the trials came out or since the time of RH 11. One of the main reasons for upgrading from RH9 to RH 2015 was to use ResponsiveHTML5 and this development impedes rollout of Responsive help.

[Captiv8r]

Sure thing

When you use Context Sensitive Help (CSH) you often employ what is called a "Map File". This file normally bears a .H file extension. And inside RoboHelp, you open the Output Setup pod and play in the Context-Sensitive Help area. Normally that allows you to establish a mapping relationship between the Context ID and the desired topic. That information is then stored in the .H file. At runtime, the .H file is used to help make the magick happen.

So the net result is that from the application, an Identifier is used to connect with the Map file and ultimately present the desired topic. (assuming all is working as planned, of course)

But there is another way that folks have been using. And with the second way, all the developer does is plug the URL pointing to the desired topic into the application. So instead of using any sort of API or whatever, the application launching point just opens the URL that was specified.

Hopefully that helps clarify. Also hoping to see others pop in with more information.

Cheers... Rick

[KFarrelly]

Thanks, we use a variation of the 'second way' mentioned in your latest email to deliver a 'context sensitive' help experience. But layered into that is the use of redirection links so we can adjust URL's that help buttons in the product point to without rewrapping the product. Each help button in our product has an RDI associated with it and the URL's for the RDI that open a help topic. This give us option to adjust the URL for the RDI as needed over time without having to adjust the product directly.

Your first email got me headed in what I think is the right direction, which was to look at how I was structuring the links for the RDI's that go with our product's help buttons. Based on your first email that shows a URL for a topic ran from your robowizard.com, I checked what the URL for a topic would be when ran from my Responsive HTML5 help's table of contents. I was missing some text or a parameter of sorts. I have since replaced the #html/ text in my original URL with the text #t=html%2F . Variation 1 and 2 below both opened the desired, specific topic from my Responsive HTML5 output -- I went with variation 1.

PS. The original format for my URL continues to work ok if the topic being called up is from a WebHelp output. Also, my earlier description of the # sign's purpose in the URL looks to be incorrect.