This content has been marked as final. Show 6 replies
Hi Todd. From what you describe you shouldn't be using webhelp at all. It is designed to sit on a server to allow updates to be applied and accessed by the users FROM their local machine. Presumably you are currently installing CHM files as part of your software TO the users local machines. You could install the webhelp output to their PCs as well as part of the applications install but there are all sorts of issues with this. The major difference is that a CHM file is a compiled single file. Webhelp is a collection of files so the application would have to know which one to call (e.g. context sensative help). Plus you can't install updates without the user knowing unless they reinstall a new version of the application.
Thanks for your reply, Colum. I'm a bit confused now as to what we should develop (Webhelp vs HTML). What solution, if any, will allow us to store and update help content in-house seamlessly, without requiring the user to take any action to receive the latest help revision?
Further, is it possible to simply link from the application (installed locally on the user's machine) to the Webhelp system?
I apologize for my naivety - my experience to this point has been in Winhelp, which was very simple to deliver.
To answer your questions you need to understand why each format was developed. HTMLhelp was developed as a successor to winhelp. It's designed to sit on a user's PC as a .CHM file. An application accesses it in much the same way as a winhelp file. Webhelp was developed to sit on a website or server and be accessed by users that could be anywhere. The help itself does not sit on a user's PC.
Currently your applications install routine probably has a piece that copies your .HLP and .CNT files to the users PC. If you go to HTMLHelp you just need to change this to copy the .CHM file - the TOC is compiled as part of the file. With webhelp, the compile process allows you to "publish" the output files (and there are numerous) to a location that can be accessed. This is normally a server or URL. It's not designed to be copied to a user's PC so is not included in the applications install routine.
Thanks again. That helped to clarify things.
Webhelp was developed to sit on a website or server and be accessed by users that could be anywhere. The help itself does not sit on a user's PC.
This would be the ideal solution for us. One final question, then, is how would a user access our Webhelp? What are the common avenues for this "through" an application? Should we simply provide a link to our Webhelp system?
Thanks again for your help. Happy Holidays!
Hi Todd. The call your application makes will be different from the previous winhelp call. Your developers should be able to help you with this. All you need to decide is where the help files will be placed and the developers should be able to point to this. With webhelp the entry page is by default the .htm file in the root directory with the same name as your project (e.g. projectname.htm). If your application has context sensative help you'll have to aim the call to the specific HTM topic file. One final point, with webhelp you can customise the look and feel of your help through the use of skins. There are several ones provided with RH and you can download others. You may want to design your own. RH allows you to do this and provides hours of fun - if you have hours available!
You have been a great help - thank you.