>>I have the help topic variables set all over the app, but no longer use it. 

we use help&manual , which is similar to robohelp.  It allows you to create help as either chm, html, pdf, hlp and other formats.  We mainly use chm , html and pdf formats.  Its great way to write the help and be able to generate it in multiple formats depending on what you need.   You can also include links to videos and other things (file or URL) too.

We use the window title as the way to have the help context sensitive.  when a user hits F1, the system grabs the current window title, strips out spaces and other characters that aren't allowed as the topic id, and that is typically the help topic.  We also have a mapping feature that looks up the object.windowname to see if there is a more specific help topic setup for the current object rather than a window.  This allows the help writer to do all the work without a developer.    

our support uses the help file when a customer calls up asking a question about how something works.   This makes sure the help is correct and clear. And it also reinforces with the customer that they could have had an immediate answer if they pressed F1.  Our approach is to tell the customer when they ask a question:  'Ok, lets press F1 and see what help says' then they read the help to them.   Improving help is constant, sometimes it is out of date, sometimes it isn't as clear as it could be.   Sometimes it forces us to change things in the application to make it clearer so help isn't as needed.  Our support calls have dropped a lot over the years as help improved.

and yes, some customers will call no matter how clear the screen/error message/help is.  

Hi Tracy.

I did used in the past HelpMaker which is discontinued. After that I've used two tools: HelpNDoc (you need to pay to use it in your business but I believe it's affordable), Precision Helper which is free.

HelpNDoc: Really easy to use. Great support. Has some great functionalities like conversion from existing HLP or CHM files to a HelpNDoc project. That means that if you have your original HLP files, then you can reuse almost all of their contents (even in windows 10). Writing contents and topics is pretty much as easy as writing a word document. Generates CHM, PDF, WebHelp sites and many other (like ebooks etc).

Precision Helper: I do like very much that tool. It's free and it's pretty simple. But you must have some html knowledge to write your content. It's really powerful. While in my previous work, they did own a HelpNDoc license, I did preferred using Precision Helper. Precision Helper allows you to create projects from existing CHM files, but has no support for HLP files. You can generate CHM, RTF, PDF (using distiller - not directly), ebooks (with some additional tools that I'm not sure if they are easy to find), WebHelp (this implementation, in my opinion, is better than the one provided by HelpNDoc).

If you need any additional information for one of those products let me know.

Andreas.

Hi Tracey,

There's many formats people use: html, rtf, chm, pdf, just to name a few. 

If you have all the "help topic variables" already set, you still might to be able to take advantage of that, but using a different format. Of course you'll have to redefine each and every one of the pages in the new format. If you have lost the previous help file, then indeed it's going to be quite a job.

Maybe a commercially interesting alternative is to create some user courses/introductions, instead of providing a help file. (personally I think that any application should have its help files, but some people don't agree on that and try to sell what should be included in the product) :)

best regards,

MiguelL

Hi Tracy;

  I used to use RoboHelp as well. A great tool in it's day for .HLP help file production. Then I switched to .CHM. Today though I use one of two approaches.

#1:  use plain HTML stored on the web server & grab it via the PB Apps using either the INet object or the newer built-in PB Web Browser control. I like plain HTML now because is easily fully searchable by any web browser or related control by the App User.

 #2: The other tact that I have used over the past decade is to produce the App help as a PDF file. Then store this in the DB or again on a Web Server. Then use the iNet object or as of late the built-in PB Web Browser control to display the PDF help. Once again, PDF's are indexable & searchable by the App user.

The  above two techniques also allowed me to centralize the App Help so that I can have one central place to deploy/update the App help. These approaches also work well with PowerClient & PowerServer based applications. Both HTML & PDF files are easily produced as well from today's word processing software products.

Food for thought. HTH 

Regards... Chris 

Update... providing Context Sensitive Help.

In most of my response windows, I've got a Help button.  The root-level ancestor (wa_response) has the following code behind the Help button:

SetPointer(HourGlass!)
ShowHelp(gs_helpfile,KeyWord!,is_keyword)

In the window's Open Event, I set is_keyword to whatever is appropriate for the window.  As long as I have a corresponding Keyword defined in HelpNDoc, the Help button opens to the appropriate topic.  If I don't have a Keyword defined, HelpNDoc opens with the general index.  Works like a charm!

~~~Tracy

If you can find the CHM help file, you can use it. This is what we did and it works well.

https://iristech.co/winhlp32-exe-on-windows-10/

You could point your Help link to SharePoint where help content is hosted - created/maintained by Product Owner and BAs using HTML, images, videos, etc. You can use just one link that always takes the user to the Help home where they can browse or search help or you could use individual page links for each topic. This way, help content evolves continuously without developers' intervention/efforts and users can read/learn about the application even outside the application by simply surfing to Help hosted on SharePoint from anywhere. You could even parameterize the base URL and links to various help sections (if they ever change, just change them in the INI file and redeploy the INI file - or maintain the URLs in a table).