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.
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:
using Slimzhao;
At your Form's constructor, add the following lines to the end:
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;
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();
}