Environment: .NET, C#
The main goal of this work is to design a control containing sensitive elements of various types. An output of the control is its current state comprised of sensitive elements states. The control should be smart and flexible enough to accommodate the bulk of the state switching functionality, leaving to its derivatives option to change only few specific features. The control’s configuration is carried out with an appropriate XML file.
In an attempt to meet the above requirements, the Open Group Control (OGC) was developed. The OGC is a UserControl-based container for sensitive elements (below referred to simply as elements). Each of these elements’ types should comply with certain rules: implement special interface IElement and be placed in a separate, dynamically loaded assembly. The elements may be of different types (non-WinForms-control-based such as the OGCVisualElement type, or based on WinForms controls such as the OGCComboBox
type), and new elements’ types may be developed without change of the OGC itself. So, OGC allows its extension by designing new types of elements.
The OGC is an evolution of the Hot Spot Control presented in another article. The concept of using visual elements (images, static and dynamic) as multi-state buttons is applied in OGCVisualElement and OGCDynamicVisualElement classes. However, important features are added:
- Open architecture
- Complete configuration with XML files
- Docking abilities
- Error handling mechanism
- Enhanced dynamics
Basic OGC, its dynamic extension “stuffed” with static and dynamic hot spot elements and combo box elements, is presented.
Assembly OGCLib contains these basic OGC types and interface definitions:
OGControl—elements container that provides main OGC functionality for mouse operations, control’s state change, initiates elements’ geometry modification, docking, and error handling mechanism.
Configurator—responsible for configuration of OGC 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 definitions for the following interfaces:
IElement—base for the element types.
IFactory—base for the element instantiation Factory classes in element type assemblies.
Assembly DynamicOGCLib contains dynamic extension of basic OGC types. Assemblies OGCVisualElementLib, OGCComboBoxLib and OGCDynamicVisualElementLib contain appropriate IElement-based element classes, and loaded dynamically by OGControl.AddElement() method using Reflection.
To create the OGC with minimum functionality, a parent form should call its constructor, passing the name of an XML configuration file as a parameter, and add newly instantiated control to its controls list:
or, for dynamic OGC
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, such as OnChangeState(), ConstructTip(), and DinamicsRule() in case of dynamic OGC may be overridden by a control’s user.
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 the error message template from XML allows a user to configure the error message and receive it in her/his native language. All OGCs and their elements in the application share this information. The error-handling mechanism makes it easy for a developer to add handling of new errors that may occur in derived classes.
OGC, using its Configurator class, reads the elements’ related data from its configuration file. Based on this data, the control loads the appropriate assembly and creates the requested element with the assembly’s Factory : IFactory class. Sample files Configurator.xml and ConfiguratorDyn.xml are examples of OGC configuration files.
OGC contains a set of elements. Each of them has several distinct states. The vector of elements’ states forms the state of the entire OGC. This relationship is represented by the Control States Matrix.
Control States Matrix definition
To describe the matrix, let’s assume that the OGC has N elements numbered from 0 to N-1. The n-th element has Mn states (from 0 to Mn-1). Let’s define state k of the entire control as a vector of mn states (n-th element in its m-th state). Assuming that control has K distinct states we get a Control States Matrix with K rows (control’s states) and N columns (elements). The matrix [k, n] cell value mn shows that if OGC is in the k-th state, its n-th element is in its m-th state. The value of [k, n] cell equaled to -1 means that any state of n-th element is “acceptable” for the OGC k-th state. The value of all cells of the matrix is set by default to -1. Values of specific cells (deferred from -1) are given in XML configuration file.
Rules for transition from one OGC state to another are defined by the State Transition Matrices. Such a matrix should be assigned to each OGC element in a configuration file. These matrices have also K rows corresponding to the OGC states. But their columns represent possible variants to change element’s state.
State Transition Matrix definition
For example, for OGCVisualElement there is only one possible variant to change its state—being clicked. So, for this type of element State Transition Matrix is reduced to a vector. The k-th coordinate of this vector equaled to knew means that if this visual element is clicked when OGC is in k-th state, the OGC will transit to the knew-th state.
On the other hand, the OGCComboBox element with Z strings in the list has Z possible variants to change its state (select any of the strings). So, the OGCComboBox element is characterized with the [K * Z] State Transition Matrix. The [k, z]-th cell of this matrix equaled to knew means that if the z-th string is selected in combo box when OGC is in k-th state, the OGC will transit to the knew-th state.
knew equaled to -1 indicates that no change in the OGC state will be made in response to this action (i.e., knew = k, but it is easier to assign -1 to knew by default). The value of all cells of the matrix (vector) is set by default to -1. Values of specific cells (deferred from -1) are given in an XML configuration file.
The docking position of the OGC is changed by dragging the control with its caption. If, after dragging, the distance between the hot spot (point where the left mouse button was released) and a side of the container form does not exceed 20% of the appropriate client area size of container form, the control will be docked to this side. As the docking position changes, positions of elements modify according to the control’s current orientation. Images also rotate + or 90 degrees when the Rotate value of the OGControl tag is set to “Yes”. Other scenarios of docking and elements geometry modification may be chosen.
The error handling mechanism is chiefly located in the OGControl class and its derivatives (such as the DyanminOGControl class). The ErrorEvent is generated when an error occurs. An object of the ErrorEventArgs class containing the error’s severity and a message is sent as a parameter to the delegate implementation. Error message templates are read from the OGCErrorMessages.xml file by the Configurator and added to appropriate list of OGControl. Message templates are listed in OGCErrorMessages.xml file starting with OGControl related, and following by the OGControl-derivatives related messages. Each of these classes has an enumerator for its error messages. Simple manipulation with quantities of errors of each class allows OGControl and its ascenders to determine the template corresponding to the error that occurred.
The current version of the OGC may be improved/extended in various ways; for example, by incorporating a design mode into the control (allow size modification, change in elements location with mouse, and define their states filling up the configuration XML file), adding more functionality employing captions, right-click floating menu (for instance, making the control invisible), and so forth. And, of course, additional types of IElement-based elements may be designed.
An Open Group Control containing sensitive elements, and several types of the sensitive elements, was presented. The OGC architecture is extendable in the sense that new element types complied with defined rules may be added to it. The control contains almost all necessary functionality and therefore spares its user from developing and debugging its ascenders. Such important features as complete configuration with XML files, docking support, an error handling mechanism, and some dynamics are incorporated to the OGC.
I will be very much grateful for constructive discussion, suggestions, and bug reports.
In the sample I use a picture (of a beetle) of an origin unknown to me. Bugs and scenario flaws are more than possible.