The CForms library

Introduction

There are applications that must show several different forms to the user. For example this happens in data-entry applications.

The MFC library provides the CFormView class but the way it is implemented leaves many problems open.

There are other solutions for creating forms but they require to change the programming language used, or they are available only on some platforms.

We have collected the most frequent requirements of form based applications and developed an object oriented framework to create forms in MFC code.

This solution is simple enough, it is composed in C++ with some MFC and it is easily extensible.

The CForms library is a library for displaying forms in MFC applications without using Windows resource templates and the MFC classes for dialog windows or form views, it loads the form description from a simple file in an XML format and provides many functions that are quite impossible in the MFC way of making forms.

General features

• The form is loaded from a file or memopry block composed in XML format. The XML format allows to extend the form definitions in the future.
• The library is very easy to use, there are no new control classes to learn, the main part is composed of 5 classes only.
• The library is available as a static library or a DLL and it is sold with complete source code.

Detailed features

• A form can contain any number of components called FormItems. There are the following predefined types of items:
• static label
• edit box (single line edit)
• combo box
• list box
• text box (multiline edit)
• check box
• radio button
• push button
• image box
• The form provides the following commands to change the state of the entire set of form items:
  • Clear
  • Enable
  • Disable
• The form provides simple functions to retrieve or set the values of the form items as a series of name and values pairs.
• Each form item has a name, an identifier, a description.
• The library provides single field validators that may be attached to a single form item. There are the following types of validators:
  • Numeric validators (integer, floating point, time, money): interval, min, max.
  • String validators: string length, string characters (alphabetic, numeric, alphanumeric etc...)
• For more complex validation rules you can provide a derived validator class to be attached to the form, or override the Validate member function.

Sample application

This sample application creates a form from a definition file. A sample definition file is provided so you can edit it manually to see what changes. The program loads and saves only files with predefined names placed in the same directory of the executable.

You can download the demo program from here. The zip file contains also the source code of the demo program to show how the classes of the library are used.

Dependencies

This library uses some classes of the MFCPlus library, however we can arrange a custom package with all the needed classes if you want.

Main classes

CFormModel	This represents a form, it contains the form items and manages them.
CFormItem	This represents a form item.
CFormWnd	This is the CWnd derived class which connects to a CFormModel and holds the child windows.
CFormParser	This is a CMarkupParser derived class with some additional methods to parse some attributes of the form and the form items.
CFormWriter	This is a CMarkupWriter derived class with some additional methods to write some attributes of the form and the form items.

Form editor

Any form editor can be easily adapted to save the form in the XML format used by this library. We have build a quite complete form editor for this library and we will release it soon.

Problems of the MFC dialogs and form views

The MFC classes for dialog windows and form views provide a basic way to create forms in MFC applications but their limits make them not the best solution for large applications with many forms.

The layout of the form components in MFC is defined with a dialog template in the Windows resource format, every component of the form has a unique numeric identifier. Then the MFC uses the Windows functions to create all the child windows of the form, so the child windows are created outside the application code, and they are reachable by means of their child identifier. To have a C++ object connected to a child window we have to add a member variable of the class used and add a call to DDX_Control or SubclassDlgItem.

If we want to provide a command to enable or disable all the form components we have to write the code again for every form, and this code is not just a series of calls to EnableWindow for each component. For example the edit controls disabled look is obtained by putting them in read only state and not by disabling them, so the code needs to use a different function for each component, and it is not possible to treat all the components in the same way.

If we want to retrieve the values of the form items we have to write code for every form, and each type of component has a different way to provide its value.

The MFC solution is to add member variables that receive the item value and add as many calls to DDX functions (DDX_Text, DDX_Int etc..), so the dialog or form object gets both a series of member objects to link to the child windows and a series of member variables to receive their values.

The same problem arises if we want to load values into the form items, each component needs a different procedure so it's not possible to write a loop that uses all the components in the same way.

Another problem of the MFC dialog resources is that they are compiled in the application executable and so they are a bit difficult to change, to modify them we have to recompile the resources and relink the executable.

The MFC provides solutions for ad-hoc dialogs and form views, but it is not enough for a large application with dozens of different forms.

The MFC dialogs and form views support custom controls but we must embed a C++ object and connect it to the child window to make it work.

The child windows have only a numeric identifier while in most applications they should have a string identifier, think of database applications where form items are connected to database fields.

But a form item could have many other attributes, for example a label, a textual description, an help identifier, a custom validation rule and so forth. This is not possible by using the MFC crude way based on simple control classes.

More information

The CForms Library is available complete of its source code and documentation.

For more information write to mail@softwaresphere.com or leave a message with this form.