We have a C++ desktop application requiring context-sensitive help. We have been using the RoboHelp WebHelp format for years; now we are migrating to the newer Multiscreen HTML5 help, using the Desktop profile only.
1) Is it possible to do this? Can a C++ desktop application call context-sensitive help using the Multiscreen HTML5 format?
2) If so, how do we call the Multiscreen HTML5 help file from the C++ API? We have been using the RH_ShowHelp API call in the C++ code provided with RoboHelp, but this call does not work with our Multiscreen HTML5 file. The RH_ShowHelp method seems to work by appending “#<id=XXXX” (where XXXX is the Map ID) to the HTML file name we call, but this does not produce a pop-up help topic using the Multiscreen HTML5, as it does using the WebHelp file.
3) Do we need to do anything special when generating the Multiscreen HTML5 help file to make it work from the C++ interface?
4) Is there another C++ API method we should be using? The available APIs in the C++ interface are:
Thank you very much for any information you can provide!
Principal Software Developer
IMCS - Abacus Technology Corp.
Kennedy Space Center, Florida 32899
Point of curiosity. Why Multiscreen? Why not opt instead for Responsive HTML5?
After all, Adobe is highly unlikely to do anything further with Multiscreen and Responsive HTML 5 is likely where all future development will be for the foreseeable future.
I hate to see folks paint themselves into corners.
I agree entirely with Rick that Responsive is where Adobe are progressing things so you will see new layouts as time progresses. Multiscreen was good if you wanted to choose entirely different layouts for each device but it wasn't as popular so responsive is the way to go. With that, each layout morphs for each device, there is no further configuration. There's more on my site and in the RoboHelp Tour that you can access from there.
I can't help you much with calling this form of help. There is information on Willam van Weelden's site and my pages on calling help have links to that.
See www.grainge.org for RoboHelp and Authoring information
Thank you, Peter and Rick. Based on your advice, we will go with the Responsive format.
Any other ideas on how to call Responsive CSH from the C++ API?
There's this post which says Adobe Support advised there was a mistake in the 2015 help. So it sounds like according to Adobe it should work. Maybe the referenced pdf and page number will tell you something new.
Linking F1 to ResponsiveHTML help -missing files
Thank you, Amebr. I follwed your link to this Adobe manual (http://help.adobe.com/en_US/robohelp/2015/robohtml/robohelp_help.pdf ) which suggests (on page 343) that what we are doing should work with the Responsive format, and that we are using the correct API call (RH_ShowHelp).
Thank you also, Rick, for the updated link to Willam van Weelden's article. It looks like a different API than we have available in C++, and the references to localhost in the HTTP address suggest the use of a local web server that we do not have. So, I don't think it applies to us.
Thank you, also, Peter. Using the actual file names (direct URLs) with hundreds of CSH help topics would be an inordinate amount of extra work for us, so we strongly prefer to use the Map IDs.
What we are doing works great with our old WebHelp files; and it works great if we switch our new files back to WebHelp format; but it does not work with the Responsive format. It seems as if the Responsive format is not working the way it should be with the documented API calls.
On page 330 of the PDF document referenced above, I found references to WebHelp and merged WebHelp* (along with a reference to your website, Peter :-)). Perhaps the documented methods work only with the WebHelp format?
* "From page 330 of http://help.adobe.com/en_US/robohelp/2015/robohtml/robohelp_help.pdf :On the Authoring home page of Peter Grainge’s website, you can find information about four methods of calling WebHelp:
• Using map IDs in merged WebHelp"
Thank you again!
From our testing, it appears the new HTML5 Responsive format and Multiscreen formats are incompatible with the RoboHelp C++ API and the .NET API provided by Adobe. Only the WebHelp format works with these native Windows application APIs. Please correct me if I am missing something here, and I will unmark this answer as correct.
[There also seems to be a bug in recent versions of the RoboHelp C++ API that prevents the display of multiple CSH help topics during a single calling program invocation. Each time you close the calling program and then restart it, you can display one CSH help topic. We are able to work around this bug by using an earlier version of the RoboHelp C++ API that we have modified and corrected.]
Thank you again!
I don't normally use the RoboHelp API's. But you can always create the URL yourself and that works like a charm for me.
The article simply shows how to build a URL that RoboHelp uses for context sensitivity. The localhost in the example is just that: an example. You can use any URL as long as the URL parameters work for you.
Thank you, Peter for the corrected links; and thank you William for the content at those links, and for the additional information. 🙂
I see now, William, that we could avoid the C++ API altogether, and craft our own URLs based on the guidance that you provide in your article (https://www.helpessentials.com/2017/08/05/context-sensitivity-in-responsive-and-multiscreen-html5/).
If we did this:
1) Is there any way to retain the features that the integrated API provides? In particular, we would like to keep the the "Show" link at the top of each CSH help topic. Clicking this link splits the help topic window, with the entire help table of contents in a pane at the left, pre-opened to the location of the CSH topic being viewed. We have something similar with the responsive help, but the table of contents is not pre-opened to the help topic being displayed.
2) If we requested a new window (using rhnewwnd=1), our customers would be subject to the pop-blocking settings of their browsers. They would need to know to enable pop-ups for the help file location we are using. How do you handle this situation? Can this requirement be avoided for our customers?
Thank you both so much!
The show link is part of the RoboHelp output. So using URL's won't matter for that. The only thing the API does is integrate with your project and build the URL in the background. There is no restriction when using your own API.