How are the devs calling the help? For WebHelp/Responsive HTML5, you normally just open a URL with some parameters. Depending on how the CHM is linked to the application, it is a simple change in the call.
If you are using context id's, those will be retained when you move to another system. Only the call will be updated. As long as your application can open a browser or URL, they can open help through F1.
RoboHelp includes sample API's for context sensitivity, including one for VB.NET. And otherwise you can make one yourself rather easily.
More info for your developers here:
Thank you for taking the time to reply. Our program is written in VB6. Old I know but still going strong with a very large user base. The VB6 interface invites you to point your application to a compiled help file. This needs to be an .hlp or a .chm. There is an 'App' object in there that you can code to directly but it only does the same thing.
We can direct a generic call for help to where we like - the problem is with context sensitivity. If a user presses F1 on a dialogue with a context sensitive help file, VB6 handles the opening of the CHM on the right page. I can't, however, tell VB6 that I want to use a suite of uncompiled HTML, so we don't know how to maintain context sensitivity if we switch to R-HTML5. I guess that might be a question more of VB6 than Robohelp but I was hoping to find someone else who had gone through the same process. The CHM viewer looks extremely dated and we were hoping to freshen things up. What is more, browser based will allow users to open multiple pages on different tabs, bookmark pages they need often, etc. Web-based could also allow us to keep the files on a server to save us shipping them. Lots of possibilities that aren't open to us with CHM.
Is there code we can write that will intercept VB6's desire to access the CHM via the help viewer?
Is there a method of stepping through a CHM, using it as an index of sorts, with a web-based page as the ultimate target?
Both these are more wishful thinking than realistic questions, but any other method of delivering what we are after would be gratefully received.
WRT "looking dated", Adobe has added an ability to compile a CHM file using a WebHelp with a skin so it looks "fresher". But I'm guessing that would just as likely mess with any mappings that were done.
And speaking of mappings, you seem to be under the impression that all one has to do is compile a CHM file and POOF! VB just somehow "knows" how to map to the right topic. Unfortunately that's vastly over simplistic. There has to be some sort of mapping operation that takes place to "connect" the correct topic with the exit point of the application.
One way to accomplish things would be to configure each landing topic so it has a redirect built into it that would point to a web page with the actual information. So the call would be made, the CHM would open and display the topic and the topic would open the web page with the actual content. But I would think that to be a very long and error prone process.
LOL yeah I know there is no 'POOF' - there is a file with mappings in it. VB6 checks what page its on and fetches an ID based on that page - if there is one. Then it opens the CHM file with the relevant page open. That's the bit we'll be losing.
Thanks for the Webhelp to CHM heads up - I didn't know that was there. It does half the job, making it look better, which is something. At least I think it will look better. The out of the box skin leaves a bit to be desired but if I get the Colouring-In Department on it (aka Marketing) I bet it will look marvellous.
Still hoping for a full-on web-based answer but you've certainly given me something to go with.
Just an amusing observation. I've seen a number of complaints over the many years I've been involved with RoboHelp. And like yours, one of the regular complaints we see is that "CHM files look dated".
What amuses me is that the help system is most often the last place a user wants to find themselves. And at that point is it really going to matter that it looks different? I mean, if it's really well done and they user finds exactly what they need in order to solve whatever their issue may be, my guess is that they wouldn't really care if it were presented as hieroglyphs on clay tablets as long as it solves their problem.
I noticed another issue you were trying to solve was saving favorites to different topics. Perhaps you are also unaware that the CHM format also includes this capability and all you have to do is turn it on?
Additionally, if you choose WebHelp as the output format, I don't believe the browser allows saving a favorite to content inside a frame set. This will likely be different if you are using Responsive HTML5. But I thought it worth mentioning.
More gold dust . No I didn't know you could have favourites, I will be switching that on.
I understand what you say about the help files being the last place, etc. However. As you can imagine written in VB6, what I have here is an old product. It is still being actively worked on, and we have put a lot of effort into keeping it relevant. It remains a leader in its field and I hope it stays there. But the look and feel can be a stick to beat us with. The product does the job but the perception of users is something we need to be aware of. There are parts of the software proper that we can't do anything about, visually, but I think a reskinning of the help, as trivial as it is, gives a good signal.
I appreciate all the tips I am offered, so thanks again. Whilst I am familiar with writing content I am very much a newbie with Robohelp building itself, having inherited the task as I'm sure many do. We used to use RH7 until recently, until the licence "went west" (don't ask), so getting the upgrade to 2015 is a boon and I'm sure there are loads of toys in there I have no lcue about.