Introduction
The presented WinForms control has three distinctive features:
- it may contain and operate any element that implements a certain uniform interface,
- its main output is its current state, and
- it is completely described and configured with XML.
The control is a UserControl-based container
for sensitive elements (below referred to as simply elements). Filled with
elements of various types, it can serve as a customizable toolbar, toolbox, or
hot spot control for different applications. The control is called Open Group Control (OGC)
since it contains and manages extendable (open) group of elements.
Advantage of such a control in comparison with, say, ordinary toolbar is that it
does not require writing user's code to handle control's internal elements and
their relationship. The OGC provides its user with reusable already compiled
(and therefore already debugged - hopefully) modules containing some useful
tools and mechanisms (like e.g., error handling).
Elements
The elements of the control should comply with certain rules: implement
special interface IElement and be placed in a separate
assembly. If element be instantiated then the element's assembly is dynamically
loaded by the control. It means that the elements may be of different types (non-WinForms-control-based type, or based on WinForms controls), and new elements� types may be developed without change
in the control
itself. So, OGC allows its extension by designing new types of elements.
Currently, two types of elements have been implemented with the following classes
OGCVisualElement - hot spot element, image acting as multi-state
buttons, and
OGCComboBox - combo box.
Element classes are implemented in separate dynamically loaded assemblies.
States
The control contains a group (set) of elements. Each of them has several distinct states.
Vector of elements' states forms the state of entire control (the control's state).
This relationship is represented by the Control States Matrix. By activating an
element (e.g., click hot spot element, select an item in combo box) user makes
control to transit from one its state to another.
Rules for such transitions should be defined for each element by the element's State
Transition Matrix. XML configuration file contains Control States Matrix for a
control and State
Transition Matrices for each of its elements. The matrices structure is
comprehensively explained in file Additional_Notes.html that can be loaded along with this article
code sample.
Composition
Assembly OGCLib contains basic types and interfaces definitions:
OGControl � elements container that provides main OGC functionality for mouse operations,
control�s state machine, docking and error handling mechanisms, initiates
elements� geometry modification.
Configurator � responsible for OGC configuration using XML file.
ErrorEventArgs � object of this class is used as a parameter in error processing delegate;
contains error severity and message.
The assembly contains definition for the following interfaces:
IElement � base for the element�s types.
IFactory � base for the element instantiation Factory classes in element type
assemblies.
Assemblies
OGCVisualElementLib and OGCComboBoxLib contain appropriate
IElement-based element classes OGCVisualElement and OGCComboBox.
These assemblies are loaded dynamically by OGControl.AddElement() method
using Reflection techniques.
Configuration
The entire control configuration data are placed in XML files. File OGCErrorMessages.xml
contains all error message templates. Currently, the name of this file is hardcoded and may not
be changed. Reading error message template from XML allows user to configure error
message and receive it in her/his native language. All OGCs and their elements
in the application share this information. The control reads elements related data from its configuration
file using Configurator class. Based on these data control loads appropriate assembly and instantiates
requested element with the assembly�s Factory : IFactory class.
Usage
To create the OGC with minimum functionality a parent form should call OGC
constructor passing name of an XML configuration file as a parameter, and add newly
instantiated control to its controls list:
Controls.Add(new OGControl("Configurator.xml"));
Delegates for processing of OGC�s StateChangedEvent and ErrorEvent
static events
delegate void StateChangedEventHandler(OGControl source, EventArgs ea);
delegate void ErrorEventHandler(OGControl source, ErrorEventArgs eea);
should be implemented.
To enhance functionality, some virtual methods, like OnChangeState() and
ConstructTip() may be overridden.
Code Sample and Additional Notes
These are available for download. The sample may be built with __RunMe_First_To_Build.bat
batch file. The batch files _Run_Example_1.bat and _Run_Example_2.bat
allow to run two related examples. File Additional_Notes.html provides more
comprehensive explanation of the matrices structure and the sample, while file
Data_to_Examples.txt contains Control States Matrices
for the examples.
Further Development
The current version of the control may be improved/extended in various ways, e.g. by incorporating
design mode to the control (allow size modification, change in elements location
with mouse and define their states filling up configuration XML file), adding more
functionality employing caption right click floating menu (for instance, making
the control invisible), etc. And, of course, additional types of IElement-based
elements may be designed.
Conclusions
An approach to WinForms control design characterizing by usage of state machine,
XML configuration and handling of uniform-interface-based internal elements
is presented. The control with its elements types is largely self-contained.
In many cases such structure can spare its user from developing and debugging of
control related code.
I will be very much grateful for constructive discussion, suggestions and
bugs reports.
Thanks
My deep thanks to .S.Rod. for his suggestions on article organization and
title.
