Best practices for integrated help in your deployed EXE

[John Lokanis]

I have been asked to implement some sort of online/integrated help system into my executable. I have not done anything like this before. (In the past I have just written word docs and published them on the internal network)

I was wondering what the best practices were for doing this. A few ideas I had were:

• Building .chm files and then linking them to controls and menus in my application. (not sure exactly how to do this).
  
• Using tip strips to supply documentation.
  
• Using a pane on the window to display help messages when requested or when hovering over certain controls.
  
• Linking to a Wiki on the corporate network.
  

I would prefer a solution that was mainly 'on demand' so advanced users would not be bothered by obtrusive help messages.

Have you implemented built-in help? What worked best for you?

Thanks for your ideas!

-John

[Stagg54]

Typically we just use the context help. If you enter a description for a control/indicator, that will show up in the context help window. You can programmatically show/hide that. So you just have a help button that pops it up. Then when they hover over a control/indicator the description shows up in the context help window.

[crelf]

• Building .chm files and then linking them to controls and menus in my application. (not sure exactly how to do this).
  
• Using tip strips to supply documentation.
  
• Using a pane on the window to display help messages when requested or when hovering over certain controls.
  
• Linking to a Wiki on the corporate network.
  

I don't know your corporate culture, but I'd say go for the first three at least. We have a documentation generator (it's old and clunky now) that does it (it sucks up all the VI descriptions, control documentation, etc, and puts them into a chm, and then adds the relative links to each chm page back into the context help for each referenced VI), and it works well for the end-user.

PS: "Using a pand on the window to display..." - I suggest you just use context help for that - it's free, it's easy to use/maintain, and is a simple keyboard shortcut away. Honestly, I think it's one of the most under-used features in custom LabVIEW apps: everyone uses it within the development environment, but hardly anyone uses it in their apps.

[Darin]

• Building .chm files and then linking them to controls and menus in my application. (not sure exactly how to do this).
  
• Using tip strips to supply documentation.
  
• Using a pane on the window to display help messages when requested or when hovering over certain controls.
  
• Linking to a Wiki on the corporate network.
  

1. Substitute html or pdf for chm and I like this option. Easy to have the file local, on the corporate network (one place to fix errors), or anywhere. There are much better tools, references and examples for dealing with html as opposed to chm.

2. In moderation, I am usually a bit inpatient with these. They seem to hide when I want them and show up in time to block what I really want. I do not need to know that the button with the stop sign picture is 'stop'. What I really like is when you have a status bar on the bottom of the window and just pop the would-be tip strip string into it.

Context Help: It is probably just me, but I find that a bit klunky for an application. Works well for the BD, but it is growing,shrinking and otherwise distracting. It is easy to learn to love it when you are the developer in charge of reinventing that wheel, but users who do not know or care about the trouble involved may not like it. (Caveat, I am too spoiled by what I can do in other application frameworks, things like balloon popups with html formatting).

I suggest you just use context help...everyone uses it within the development environment..

I have a pile of Kudos on a different forum because that is a patently false statement.

[crelf]

I have a pile of Kudos on a different forum because that is a patently false statement.

1. Substitute html or pdf for chm and I like this option.

The tool we have in house builds html, builds the chm from the thml, then deletes the html - one of the most used features is a checkbox that keeps the html that's generated

Why? Because the html is easily indexed by our internal sharepoint system - which kind-of ties into the intranet wiki idea.

[Tim_S]

Typically we just use the context help. If you enter a description for a control/indicator, that will show up in the context help window. You can programmatically show/hide that. So you just have a help button that pops it up. Then when they hover over a control/indicator the description shows up in the context help window.

Is the context help box available in an executable?

[PaulL]

Yes

Is the context help box available in an executable?

Yes!

[Stagg54]

Context Help: It is probably just me, but I find that a bit klunky for an application. Works well for the BD, but it is growing,shrinking and otherwise distracting. It is easy to learn to love it when you are the developer in charge of reinventing that wheel, but users who do not know or care about the trouble involved may not like it. (Caveat, I am too spoiled by what I can do in other application frameworks, things like balloon popups with html formatting).

Maybe it would be worth writing an xcontrol with a string indicator and have the xcontrol monitor the parent vi (not sure if that is the right terminology) and whenever the user hovers over a control, the xcontrol would display the help description of the control (that is being hovered over). It seems like you ought to be able to do that.

Although that seems like a lot of work.

Also the other way that context help breaks down is with subpanels. When you hover over a control inside the subpanel, LV only displays the context help for the subpanel itself, not for the control within the subpanel vi that you are hovering over. Hope that description makes sense. What I've done to compensate is just write a simple vi that runs in parallel and knows what vi is loaded and has a reference to the subpanel control and then whenever you hover over a control in that vi (detected using dynamic events), it updates the description (and possibly caption) of the subpanel control (using VI server), effectively "fooling" LV. LV is still displaying the description (and caption) for the subpanel control, the description is just changing on the fly to match which control the user is hovering over.

Hope that all makes sense. That seems to work for us.

[mje]

Is the context help box available in an executable?

Yes

...and unfortunately can't be easily disabled if you don't want it.

I agree with Darin, it's too klunky and I don't think it has any place in most executables.