Introduction
In a GUI, events are used to capture
user interactions with the GUI. Some such events are
Button
clicks, changes to
CheckBox
state (checked or unchecked), changes in the value of
NumericUpDown
controls, etc. In many cases, the event associated
with any GUI component is handled by an event handler that is unique
to a single control. This tip provides an alternative method.
The Usual Method
What usually appears for two Button controls, named some_button
and some_other_button, is:
void some_button_Click ( object sender,
EventArgs e )
{
}
void some_other_button_Click ( object sender,
EventArgs e )
{
}
The Proposed Method
The event handlers for all instances of a given type of control are
combined into one event handler. The trick is to assign different
values to the Tag properties of
each Button.
For example, if the
Tag of the some_button
control is specified as "some_button" and the
Tag of the
some_other_button control is specified as "some_other_button",
then the event handler for both Button controls can become:
void BUT_Click ( object sender,
EventArgs e )
{
Button button = ( Button ) sender;
string tag = button.Tag.ToString ( ).
ToUpper ( ).
Trim ( ).
Replace ( '_', '-' );
switch ( tag )
{
case "SOME-BUTTON":
break;
case "SOME-OTHER-BUTTON":
break;
default:
throw new ApplicationException (
String.Format (
"{0} is not a recognized Button Tag",
button.Tag.ToString ( ) ) );
}
}
A few notes.
- Tag is an object so its
ToString method must be invoked.
- MSDN suggests that comparisons should be made using upper-case.
- The replacement of underscores by hyphens allows for
Tags that are not formed in
exactly the same way.
- All
Tags must be processed within the
switch statement. If a
Tag for a
Button whose Click
event handler is defined as a common Click event handler is not
processed in the
switch
statement, an exception will be thrown.
Advantage
This method of handling events in a common event handler has the
advantage of placing event handling for a-like controls into one
method. In turn, this simplifies code and reduces maintenance efforts.
In 1964, I was in the US Coast Guard when I wrote
my first program. It was written in RPG (note no suffixing numbers). Programs and data were entered using punched cards. Turnaround was about 3 hours. So much for the "good old days!"
In 1970, when assigned to Washington DC, I started my MS in Mechanical Engineering. I specialized in Transportation. Untold hours in statistical theory and practice were required, forcing me to use the university computer and learn the FORTRAN language, still using punched cards!
In 1973, I was employed by the Norfolk VA Police Department as a crime analyst for the
High Intensity Target program. There, I was still using punched cards!
In 1973, I joined Computer Sciences Corporation (CSC). There, for the first time, I was introduced to a terminal with the ability to edit, compile, link, and test my programs on-line. CSC also gave me the opportunity to discuss technical issues with some of the brightest minds I've encountered during my career.
In 1975, I moved to San Diego to head up an IR&D project,
BIODAB. I returned to school (UCSD) and took up Software Engineering at the graduate level. After BIODAB, I headed up a team that fixed a
stalled project. I then headed up one of the two most satisfying projects of my career, the
Automated Flight Operations Center at Ft. Irwin, CA.
I left Anteon Corporation (the successor to CSC on a major contract) and moved to Pensacola, FL. For a small company I built their firewall, given free to the company's customers. An opportunity to build an
air traffic controller trainer arose. This was the other most satisfying project of my career.
Today, I consider myself capable.