Click here to Skip to main content
15,892,161 members
Articles / Desktop Programming / Windows Forms
Article

Context Help authoring anywhere/anytime/anyone for .NET application

Rate me:
Please Sign up or sign in to vote.
1.40/5 (3 votes)
6 Dec 2007CPOL3 min read 21K   119   19  
Write context Help anywhere/anytime/anyone for .NET application
Title:       Context Help authoring anywhere/anytime/anyone for .NET application
Author:      rufei zhao
Email:       slimzhao@21cn.com
Member ID:   2308266
Language:    C#
Platform:    .NET 1.1+  etc
Technology:  .NET/C#
Level:       Beginner, Intermediate, Advanced
Description: An article on howto make authoring the context help for UI easier.

Press Shift when clicking the control which request help will bring the context help authoring window out

using the EasyHelp component in your code

Introduction

I started a sourceforge project for this, for detail and progress tracking, please visit http://nethelpanywhere.sourceforge.net/

The normal way to add context help feature to .NET/Forms, is to add a HelpProvider component to each Form, then edit the help string in the property grid panel for each UI element such as Buttons, RadioButton, CheckBox, ComboBox etc. This is tedious, programmers are not the right one the write the help info for the application, especially for multi-language support applications.

In a typical product cycle, changing of the help string/Icon/Color adjustment is always the repeatedly, endless process. And, for such a non-code issues, you as a developer are forced to integrate these resource and rebuild the whole solution.

This article introduce a new way for context help authoring. With this method, the help string for multi-language are dynamically load/written for the living applications. The help string are stored in xml file. Everyone running the application has the ability to write down anything about howto use a UI element such as an obscure Button. And, the help written by many peoples can be merged into one, so this is also a distributed context help authoring system.

If you like you can also open this feature to the end user, so users of your application have the ability to write down their own idea about what your UI elements does and howto use /or avoid to use it, and share it with others.

Using the code

To use the component,

At first add a reference to EasyHelp.dll
Then add the following line to the top of your pre:
C#
using Slimzhao;
At your Form's constructor, add the following lines to the end:
C#
EasyHelpString.AddNonParentUserControl(true, null);
EasyHelpString.InitHelpProvider(this);

Variable or class names should be wrapped in <code> tags like this.

Points of Interest

EasyHelp depend on the fact that Control has a Name property, and Visual Studio IDE will generate a unique name for each control, for developers, it's very little chance for you to notice this property and it's always useless.
Here's also comes the drawback of easyhelp: Controls of same parent must specify a unique name, so Visual Studio generated UI, this is not a issue since IDE will generate different name for each UI. For more complicated UI such as dynamical ui, designer will probably to leave the Name property out.

Maybe the new version of EasyHelp should depend on the Z-order to identify each control.

EasyHelp register the ContextHelp handler, and check the whether the Shift key is pressed when this event is triggered. If so brings up the context help authoring window, and if not just do the old thing which is popup the help string.

Microsoft won't allow you combine the minimize box/maximize box/Close box and the "?" help box box/Help box arbitrarily, so if you want to use the context help for forms without "?" box, you need to trigger the event by yourself.

But you cannot do it by just send the message. A first thought of mine is to do it in a Button's click handler, such as :

private void m_btn_help_Clicked(object sender, System.EventArgs e)
{
  DefWindowProc(this.Handle, WM_SYSCOMMAND, SC_CONTEXTHELP, 0);
}
The above code won't work because of the Button's window procedure do something else when the handler returns, which bring the context help state out. I use the following trick as a workaround:
private void m_btn_help_Clicked(object sender, System.EventArgs e)
{
  if( m_hlpbtn_timer == null)
  {
    m_hlpbtn_timer = new Timer();
    m_hlpbtn_timer.Interval = 100; //100 milli-seconds , 1/10 seconds
    m_hlpbtn_timer.Tick += new EventHandler(m_timer_Tick);
  }
  m_hlpbtn_timer.Start();
}
private void m_timer_Tick(object sender, EventArgs e)
{
  DefWindowProc(this.Handle, WM_SYSCOMMAND, SC_CONTEXTHELP, 0);
  m_hlpbtn_timer.Stop();
}

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer
China China
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

 
-- There are no messages in this forum --