Jump to content

Best practices for integrated help in your deployed EXE


Recommended Posts

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

Link to comment

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.

  • Like 2
Link to comment
  • 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.

Link to comment
  • 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. :D

  • Like 1
Link to comment
I have a pile of Kudos on a different forum because that is a patently false statement. :D

:lol:

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.

Link to comment

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?

Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.