Please note that the demo executable requires the form designer source code to be built first unless the redistributables have been downloaded and registered in advance.
Introduction
If like me, you may have come across the situation where users of your product need to extend or customise the standard functionality provided by your application straight out of the box. For example, a database application may provide tools which allow users to create their own forms for viewing or entering data rather than having to go through the standard table view. Another example would be an installation package which allows each of the installation screens to be customised to suit virtually any type of install situation, no matter how diverse. What is needed then, is something that is either going to be extremely tightly coupled to the target application so as to make it unusable in any other circumstances, or, as presented here, a generic solution approaching a very simplistic programming environment where users can design their own forms and add functionality to them without having to go out and buy a copy of Visual Studio.
Components
Let's look at what we get with the form designer then.
Form editor
The form editor allows users to visibly design forms which will be executed at runtime. Each form is built up using a number of ActiveX controls. The ActiveX controls used on the form can either be selected from a bunch of controls installed on the users system, or from a number of intrinsic controls included with the form designer package. The form editor can be used to programmatically generate forms without any user interaction if required, this feature is extremely useful when forms need to be dynamically generated on the fly, or when the user has no knowledge of writing script code.
Key features of the form editor
- Creates forms up to 2500x2500 pixels
- Hosts an unlimited* wide range of ActiveX controls
- Provides standard clipboard operations
- Provides unlimited* undo and redo levels
- Includes many alignment, spacing, sizing and ordering options
- Supports both programmatic and manual form creation and manipulation
- Has a fully customizable colour scheme to suit the host application
- Flicker free operation
Unlimited* - is dependant on system resources.
Property frame
The property frame is where the appearance of the form can be totally customised. In addition to displaying a standard set of property pages for each control hosted on the form, the property frame also includes a property browser, which allows powerful manipulation of control properties, and an extended page, for setting miscellaneous control attributes, such as the control name.
The property browser supports the following property types
- String
- Numeric
- Boolean
- Enumerator
- Colour
- Font
- Picture
Context menu
Not really a separate component, but worth mentioning here. The context menu serves two main purposes. 1) To provide a shortcut to some of the more common form editor functions without having to go through menu items and toolbars. 2) To allow events which are sourced from the form, from controls on the form, and from exposed objects, to be navigated and handled by adding the appropriate subroutine blocks to the script.
The context menu provides access to the following functions
- Standard clipboard operations
- Control z-ordering (send to back, bring to front)
- Form event handling and navigation
- Control event handling and navigation
- Exposed object event handling and navigation
- Control creation and deletion
- Property frame activation
Script editor and 3rd party editor drivers
The script editor acts as a visual buffer for the script and provides a simple means to modify and expand the event handler subroutine blocks generated by the form editor. Since the interface between the script and script editor is completely based around COM interfaces, it is possible to use a specially written driver to substitute the default editor with preferred editor if required. The picture shows the CodeSense syntax highlighting editor being used as the script editor.
Drivers for the following editors are included with the form designer
- CodeMax (Version 2 only)
- CodeSense (Version 2 only)
Form viewer
The form viewer is used to display a previously saved form and run the associated script.
Control pack
The form designer includes a control pack which contains a number of useful ActiveX controls that can be used in the creation of custom forms.
The control pack contains the following ActiveX controls
- Label
- Picture
- Button
- Check box
- Radio button
- Text box
- List box
- Combo box
- Horizontal scrollbar
- Vertical scrollbar
Prerequisites
Before we can get started on building the form designer projects, there are a couple of files which are needed by the build process that may not be on your machine.
- Microsoft Windows Script Control (which can be found here[^])
- Windows Template Library 7.1 (which can be found here[^])
Building the core projects
The form designer core components are contained within two separate projects, DDPropPageAll and DDForms. Each of the projects should be built using Visual Studio .NET 2003, and in the order shown.
DDPropPageAll
This project contains the property browser implementation.
DDForms
This project contains the implementation of the form editor, form viewer, and a simple script editor.
Building the optional projects
The form designer optional components are contained within four separate projects, DDControlPack, CodeMaxDriver, CodeSenseDriver, and DDUnlock. Each of the projects should be built using Visual Studio .NET 2003, the order is unimportant.
DDControlPack
This project contains the implementation of a number of useful ActiveX controls which can be used in the creation of custom forms.
CodeMaxDriver
This project contains the implementation of the CodeMax driver which is used to replace the standard script editor with the CodeMax syntax highlighting editor. In order to build this project the CodeMax editor will need to be installed on the system in a location where the compiler is able to extract type information from it.
CodeSenseDriver
This project contains the implementation of the CodeSense driver which is used to replace the standard script editor with the CodeSense syntax highlighting editor. In order to build this project the CodeSense editor will need to be installed on the system in a location where the compiler is able to extract type information from it.
DDUnlock
This project contains the implementation on an unlock code generator which will be needed to unlock the form designer from evaluation mode into full mode.
Using the components
Introduction
Once all the projects have been successfully built up we can start looking at integrating the form designer into our own products. This section covers the steps involved in adding the form designer to a Visual Basic application. A new application is developed from scratch which provides minimalist form editing capabilities. In order to build up on the example, it is simply a case of exposing more of the component methods using toolbar buttons and menu items.
The finished application is shown below.
Step 1 - Add a reference to the form designer
The first thing we need to do it tell Visual Basic about the form designer components. From the Visual Basic components dialog, select DaeDoe Forms and then click OK. This will add the form designer components to the current project. You will notice that a number of new icons appear on the Visual Basic control palette, these icons allow the form designer components to be added to a Visual Basic form.
| Control Pallet Icon | Component |
| Form Editor |
| Form Viewer |
| Script Editor |
Step 2 - Insert the form editor and script editor components
Next, the form editor and script editor components should be added to the main form. This can be done by using the new form editor and script editor icons displayed on the Visual Basic control palette. As can be seen, each component is displayed on the same form, but this is not essential. In order for the form editor to function correctly it needs to be linked to the script editor, the link is not automatic and must be set up by the host application at run time. An ideal place to perform this connection is as part of the Form's Load event processing.
Private Sub Form_Load()
FormEditor1.Script.Editor = SimpleScriptEditor1.Object
End Sub
Step 3 - Expose objects
Object exposing is described in a later section, but basically the form editor needs to know about any objects which the script will have access to at runtime. An instance of each of these objects must be exposed to the form editor in order for them to appear in the Exposed Objects section of the form editor context menu. An ideal place to perform the object exposing is as part of the Form's Load event processing. Note that in order to successfully expose Visual Basic classes, the project needs to be set up as an ActiveX project otherwise type information for each class is not automatically generated.
Public MyClassInstance As New MyClass
Private Sub Form_Load()
FormEditor1.Expose "MyClass", MyClassInstance
End Sub
Step 4 - Add required functionality
Depending on the nature of the host application, as much or as little functionality of the form editor and script editor components can be presented to the end user as required. Most of the component methods will map directly onto toolbar buttons and menu items with a minimal of amount of additional coding. In the example, load and save buttons have been added to the main form, along with a file name edit box. Pressing the load or save buttons will direct the form editor to serialise the form as appropriate.
Private Sub Load_Click()
FormEditor1.LoadFromFile FileName
End Sub
Private Sub Save_Click()
FormEditor1.SaveToFile FileName
End Sub
Step 5 - Insert the form viewer component
Now that the form editing side of things has been completed, it is time to add a form viewer to the project. The form viewer will allow us to display a form which has been previously saved to disk by the form editor. The form viewer component should be added to a separate popup window. This can be done by using the new form viewer icon displayed on the Visual Basic control palette.
Step 6 - Load and display a saved form
In the final step, a preview button has been added to the main form. Pressing this button will bring up the form viewer window created in the previous step and load in the form whose name appears in the file name edit box. Again, you may notice from the code snippet another magical reference to object exposing, don't worry about this for now, this will all be explained in a later section.
Private Sub Preview_Click()
Form2.FormViewer1.Expose "MyClass", MyClassInstance
Form2.FormViewer1.LoadFromFile FileName
Form2.FormViewer1.BackColor = Form2.FormViewer1.Form.BackColor
Form2.Show vbModal
End Sub
Using the mouse
Before we take a look at using the form designer to create a custom form, let us spend a few moments looking at how the mouse is used in the form editor. There are a small number of form editor operations which can only be performed using the mouse, and these operations are discussed below.
Selecting controls
A control can selected by clicking it with the mouse. To select multiple controls, the ctrl key should be held down while clicking each control in turn. An alternative method of selecting either single or multiple controls is to use a selection box. A selection box is created by clicking the form, and then dragging the mouse over the controls which require selecting. Any control which is fully enclosed by the selection box will be selected.
Sizing and moving controls
When a control is selected, a drag frame containing drag handles will appear around its borders. To size a control, the mouse should be positioned over an enabled drag handle and dragged until the control is set to the required size. The corner drag handles will resize the control both horizontally and vertically, while the side drag handles resize only in one direction. To move a control, the mouse should be used to drag the control to a new location. If the grid is visible, all sizing and moving operations will snap to the grid, to prevent this, the alt key should be held down while moving the mouse.
Ordering controls
In order to set the z-order in which controls are displayed on the form, the form editor must be switched into tab ordering mode. When in this mode, each control will display a number in the top left corner indicating the control tab number. Each control should then be clicked in turn, with the first control clicked representing the bottom most control, and the last control clicked representing the top most. The form editor will remain in tab ordering mode until the area outside of a control is clicked.
Selecting and sizing the form
The form can be selected and sized in a way similar to that described in the preceding sections covering controls.
Displaying the context menu
The context menu can displayed by right clicking on the form or a control.
Creating custom forms
Introduction
This section covers the steps involved in creating custom forms using a form designer enabled application. We will look at developing a simple media player which utilizes the Microsoft Windows Media Player ActiveX control. The host application is assumed to be the standard demonstration application (downloadable at the top of this article) as this provides a complete set of form creation, editing and viewing tools.
The finished form is shown below.
Step 1 - Create the interface
The form provides a foundation on which an interface can be built. An interface is constructed by adding one or more controls to the form, these controls can be sized and positioned within the form boundaries as required.
At this stage, the following controls should be added to the form.
| Button | Item |
| Text box |
| Button |
| Check box |
| ActiveX control (Microsoft Windows Media Player) |
Since the Microsoft Windows Media Player is not made available through a toolbar button, it must be added by selecting it from a list of ActiveX controls installed on the system. The resulting form should look something like the one shown below.
Step 2 - Set the properties
The look and feel of an interface can be changed to suit any particular application by manipulating the properties of the form, and of the controls contained within the form. To allow easy property manipulation, the form editor will display a property frame containing a set of property pages for the current selection in response to either selecting the properties menu item from the form editor context menu or by clicking the properties button (shown below).
In addition to displaying a standard set of property pages, the property frame also includes two additional pages implemented by the form editor. A property browser, which allows powerful property manipulation, and an extended page, for setting miscellaneous attributes. The property browser appears on the all tab and is shown below, while the extended page appears on the extended tab.
At this stage, the following item properties should be set. Note that the Name property is accessible from the extended tab.
Text box
| Property | Value |
| Name | FileName |
Button
| Property | Value |
| Name | Play |
| Text | Play |
Check box
| Property | Value |
| Name | AutoRepeat |
| Text | Auto Repeat |
Microsoft Windows Media Player
| Property | Value |
| Name | MediaPlayer |
| ShowControls | False |
The resulting form should now look something like the one shown below.
Step 3 - Write the code
In order to add functionality to an interface, it is necessary to develop script code (using VBScript syntax) which performs tasks in response to events fired from various sources. The possible sources of events are, the form, controls contained within the form, and exposed objects. The form editor provides generation of skeletal event handlers which can be modified and expanded as required using the script editor.
To add an event handler to the script for a form or control generated event
- Right click the event source within the form editor in order to display the context menu.
- Highlight the Events menu item, a sub menu will be displayed listing all the events for the source.
- Select the event which requires handling.
A typical form or item event menu is shown below.
To add an event handler to the script for an exposed object generated event
- Right click anywhere within the form editor in order to display the context menu.
- Highlight the Exposed Objects menu item, a sub menu will be displayed listing all the exposed objects.
- Highlight the exposed object which is the event source, a sub menu will be displayed listing all the events for the exposed object.
- Select the event which requires handling.
A typical exposed object event menu is shown below.
Once an event handler has been added to the script, an tick will appear next to the relevant event menu item, clicking this will cause the script editor to jump to the first line of the event handler.
Referencing the form
The form can be referenced from the script by using the form name. The form name is fixed as "Form". For example
Form.DoSomething
Referencing controls
A control can be referenced from the script by using the control name. The control name can be set from the extended tab of the control property frame. For example
Button1.DoSomething
Referencing exposed objects
An exposed object can be referenced from the script by using the object name which was used when exposing the object. For example
Object1.DoSomething
Checking for errors
Once the code has been written, it should be checked for errors since it is not be possible to load a form containing erroneous code into the form viewer. Pressing the button shown below will perform the required checks and report any errors found.
Now that we understand all about writing script code, the following event handlers should now be added to the script.
Form - Load event handler
Sub Form_Load ( )
AutoRepeat = 1
End Sub
Play - Click event handler
Sub Play_Click ( )
MediaPlayer.FileName = FileName
End Sub
AutoRepeat - Click event handler
Sub AutoRepeat_Click ( )
If AutoRepeat = 1 Then MediaPlayer.PlayCount = 0
If AutoRepeat = 0 Then MediaPlayer.PlayCount = 1
End Sub
The resulting form should look something like the one shown below when playing a media clip.
Script constants reference
The following constants are defined in the script and can be used in place of hard coded values.
Visual Basic programmers will probably find many of these constants very familiar.
Key codes
| Constant | Meaning |
| ddKeyLButton | Left mouse button |
| ddKeyRButton | Right mouse button |
| ddKeyCancel | CANCEL key |
| ddKeyMButton | Middle mouse button |
| ddKeyBack | BACKSPACE key |
| ddKeyTab | TAB key |
| ddKeyClear | CLEAR key |
| ddKeyReturn | ENTER key |
| ddKeyShift | SHIFT key |
| ddKeyControl | CTRL key |
| ddKeyMenu | MENU key |
| ddKeyPause | PAUSE key |
| ddKeyCapital | CAPS LOCK key |
| ddKeyEscape | ESC key |
| ddKeySpace | SPACEBAR key |
| ddKeyPageUp | PAGE UP key |
| ddKeyPageDown | PAGE DOWN key |
| ddKeyEnd | END key |
| ddKeyHome | HOME key |
| ddKeyLeft | LEFT ARROW key |
| ddKeyUp | UP ARROW key |
| ddKeyRight | RIGHT ARROW key |
| ddKeyDown | DOWN ARROW key |
| ddKeySelect | SELECT key |
| ddKeyPrint | PRINT SCREEN key |
| ddKeyExecute | EXECUTE key |
| ddKeySnapshot | SNAPSHOT key |
| ddKeyInsert | INSERT key |
| ddKeyDelete | DELETE key |
| ddKeyHelp | HELP key |
| ddKeyNumlock | NUM LOCK key |
| ddKeyA | A key |
| ddKeyB | B key |
| ddKeyC | C key |
| ddKeyD | D key |
| ddKeyE | E key |
| ddKeyF | F key |
| ddKeyG | G key |
| ddKeyH | H key |
| ddKeyI | I key |
| ddKeyJ | J key |
| ddKeyK | K key |
| ddKeyL | L key |
| ddKeyM | M key |
| ddKeyN | N key |
| ddKeyO | O key |
| ddKeyP | P key |
| ddKeyQ | Q key |
| ddKeyR | R key |
| ddKeyS | S key |
| ddKeyT | T key |
| ddKeyU | U key |
| ddKeyV | V key |
| ddKeyW | W key |
| ddKeyX | X key |
| ddKeyY | Y key |
| ddKeyZ | Z key |
| ddKey0 | 0 key |
| ddKey1 | 1 key |
| ddKey2 | 2 key |
| ddKey3 | 3 key |
| ddKey4 | 4 key |
| ddKey5 | 5 key |
| ddKey6 | 6 key |
| ddKey7 | 7 key |
| ddKey8 | 8 key |
| ddKey9 | 9 key |
| ddKeyNumpad0 | 0 key |
| ddKeyNumpad1 | 1 key |
| ddKeyNumpad2 | 2 key |
| ddKeyNumpad3 | 3 key |
| ddKeyNumpad4 | 4 key |
| ddKeyNumpad5 | 5 key |
| ddKeyNumpad6 | 6 key |
| ddKeyNumpad7 | 7 key |
| ddKeyNumpad8 | 8 key |
| ddKeyNumpad9 | 9 key |
| ddKeyMultiply | MULTIPLICATION SIGN (*) key |
| ddKeyAdd | PLUS SIGN (+) key |
| ddKeySeparator | ENTER key |
| ddKeySubtract | MINUS SIGN (-) key |
| ddKeyDecimal | DECIMAL POINT (.) key |
| ddKeyDivide | DIVISION SIGN (/) key |
| ddKeyF1 | F1 key |
| ddKeyF2 | F2 key |
| ddKeyF3 | F3 key |
| ddKeyF4 | F4 key |
| ddKeyF5 | F5 key |
| ddKeyF6 | F6 key |
| ddKeyF7 | F7 key |
| ddKeyF8 | F8 key |
| ddKeyF9 | F9 key |
| ddKeyF10 | F10 key |
| ddKeyF11 | F11 key |
| ddKeyF12 | F12 key |
| ddKeyF13 | F13 key |
| ddKeyF14 | F14 key |
| ddKeyF15 | F15 key |
| ddKeyF16 | F16 key |
Shift key masks
| Constant | Meaning |
| ddShiftMask | Shift key mask |
| ddCtrlMask | Ctrl key mask |
| ddAltMask | Alt key mask |
Mouse buttons
| Constant | Meaning |
| ddLeftButton | Left mouse button |
| ddRightButton | Right mouse button |
| ddMiddleButton | Middle mouse button |
Exposing host application objects
So far we have created a nice little form which displays a media clip, but this isn't very useful if the idea was to develop something which integrates tightly with the host application. At this point you may be wondering how the form can communicate with objects contained within the host application? The answer to this is very simple, and is all to do with object exposing.
Accessing the object model
It is possible for the script to access any COM object contained within the host application by simply telling the form viewer about these objects when a form is loaded. When an object is exposed, it is given a name by which the script can reference the object. For example, if the host application were a word processor built around the standard Application->Documents->Windows object model, you may wish to expose the Application root object to the script, in this case the script would be able to manipulate all aspects of the Application object along with the associated Documents and Windows objects too. The script writer would be able to save out all documents by writing code something like this
Dim doc As Object
For Each doc In Application.Documents
doc.Save "Filename.txt"
This simple example would probably expose too much of your applications internal functionality though, and for security reasons you may choose instead to expose some lesser part of the object model. An alternative would be to expose a proxy COM object which would internally communicate with the application object model in a safe manner, this approach is also useful if the host application is not built around COM objects.
Handling object model events
We have seen how easy it is to access objects which exist within the host application using object exposing, but the integration is not yet complete. A way is also needed to handle events in the script which are fired by objects contained within the host application. Fortunately, the form editor takes care of these complexities for us. You may recall that as part of the form editor initialisation, it was necessary to inform the form editor about all objects the script would have access too at run time. Well, now the purpose of this mysterious step suddenly becomes clear. When an object is exposed to the form editor, a list of events which the object fires appears under the Exposed Objects menu item. By choosing an event from the menu, an event handler is added to the script, and the relevant code to handle the event can then be added by the script writer.
3rd party editor support
While the script editor provided with the form designer may be sufficient for many applications, it is also possible to use a number of third party editors in place of this which provide extended functionality such as syntax highlighting, auto indentation, text searching, etc. A number of drivers which allow several popular third party editors to be used as the script editor are provided with the form designer. These drivers are implemented as simple COM components which act to proxy all communications between the required script editor interfaces and the available third party editor interfaces. An example of using the CodeMax editor and CodeMax driver combination is given below. Since each of the drivers operate in an identical manner this example can be extended to included all editor and driver combinations.
As you may recall from the section on creating a sample Visual Basic host application, normally the host application will connect the script editor to the script directly.
FormEditor.Script.Editor = SimpleScriptEditor.Object
To use the CodeMax editor, it is necessary to first connect the CodeMax editor to the CodeMax driver, and then connect the CodeMax driver to the script instead. Once this has been done the script will be able to successfully communicate with the CodeMax editor through the CodeMax driver.
Dim CodeMaxDriver As New CodeMaxDriver.Driver
CodeMaxDriver.Editor = CodeMax.Object
FormEditor.Script.Editor = CodeMaxDriver
MFC host application considerations
So far we have only looked at using the form designer components within a Visual Basic host application, when using them as part of an MFC host application things stay pretty much the same, except for when it comes to handling the keyboard, and in this case it is necessary to bypass or extend the internal handling of keyboard input to ensure the components have chance to translate keyboard accelerators, and also to allow keyboard input to arrive at the correct destination without interference. Regardless of class, the component parent window should override PreTranslateMessage in order to provide this logic.
The example shows an override of PreTranslateMessage in a CView derived class, and provides sufficient functionality for most applications. The example assumes each component has been wrapped in an MFC generated class. You can probably work out what is happening here.
if(pMsg->message < WM_KEYFIRST || pMsg->message > WM_KEYLAST)
{
return CView::PreTranslateMessage(pMsg);
}
CWnd *pWndMsg=FromHandle(pMsg->hwnd);
if(pWndMsg==NULL)
{
return CView::PreTranslateMessage(pMsg);
}
CComPtr<IUnknown> spUnknown;
if(IsWindow(m_FormEditor))
{
if(*pWndMsg==m_FormEditor ||
m_FormEditor.IsChild(pWndMsg))
{
spUnknown=m_FormEditor.GetControlUnknown();
}
}
if(IsWindow(m_SimpleScriptEditor))
{
if(*pWndMsg==m_SimpleScriptEditor ||
m_SimpleScriptEditor.IsChild(pWndMsg))
{
spUnknown=m_SimpleScriptEditor.GetControlUnknown();
}
}
if(IsWindow(m_FormViewer))
{
if(*pWndMsg==m_FormViewer ||
m_FormViewer.IsChild(pWndMsg))
{
spUnknown=m_FormViewer.GetControlUnknown();
}
}
if(spUnknown!=NULL)
{
if(CWnd::PreTranslateMessage(pMsg))
{
return TRUE;
}
CComQIPtr<IOleInPlaceActiveObject> spOleInPlaceActiveObject(spUnknown);
if(spOleInPlaceActiveObject!=NULL &&
spOleInPlaceActiveObject->TranslateAccelerator(pMsg)!=S_FALSE)
{
return TRUE;
}
ASSERT(FALSE);
(void)TranslateMessage(pMsg);
(void)pWndMsg->SendMessage(pMsg->message,pMsg->wParam,pMsg->lParam);
return TRUE;
}
return CView::PreTranslateMessage(pMsg);
Unlocking the full version
The form designer component is locked down by default, and imposes a few restrictions unless it is unlocked at run time. The unlocking process is fairly straightforward and involves generating an unlock code which needs to be passed to a hidden method on the form editor each time it is run to remove the restrictions. The DDUnlock project can be used to create your own personal unlock codes, or you can just choose one from the short list below.
Data1=355EFB54-55385022, Data2=019954C1-4ED0972B
Data1=BA1C035F-E0DD33E5, Data2=BB27F80A-20A88BFF
Data1=69704745-21B4BE50, Data2=32F981BA-759362D5
Data1=3BE83CBE-F79F5195, Data2=B1CFCB3C-D0AB703E
Data1=730B783B-CD0C524E, Data2=C33CDC3D-9DA352F2
Data1=33000250-5F3FA3EB, Data2=D8CAE4F7-9F0F9D2D
Data1=0E401D8F-5DE8DE3B, Data2=9320BBA9-37DD2788
Data1=53133F9B-435D6FBB, Data2=C5C480C2-709A6B65
Once you have selected a code, simply call the DDUnlock method on the form editor passing in each of the 32-bit unlock components. For example, using the first unlock code, DDUnlock would be called with the following four parameters, 0x355EFB54, 0x55385022, 0x019954C1, 0x4ED0972B. Note that the numbers are in hexadecimal format so a suitable prefix needs to be added depending on which programming language is in use.
Distribution
This section covers the form designer redistributables and prerequisites.
Please note that only binaries from official packages located at my website[^] can be distributed at this time. But also see the section on customised distribution if you need the flexibility to distribute your own packages.
Core redistributables
In order to successfully execute form designer enabled applications, it is vital that the target system contains the following files.
DDFORMS.DLLContains the form editor, form viewer, and script editor components.
(This file should be registered using regsvr32)
DDPROPPAGEALL.DLLContains the property browser.
(This file should be registered using regsvr32)
Optional redistributables
The following files can optionally be installed on the target system.
DDCONTROLPACK.DLLContains a number of controls which can be used to create custom forms.
(This file should be registered using regsvr32)
CODEMAXDRIVER.DLLContains the CodeMax syntax highlighting editor driver.
(This file should be registered using regsvr32)
CODESENSEDRIVER.DLLContains the CodeSense syntax highlighting editor driver.
(This file should be registered using regsvr32)
Prerequisites
In order for form designer redistributables to function correctly, it is vital that the target system contains the following files.
MSSCRIPT.OCXMicrosoft Script Control.
(This file should be registered using regsvr32)
Customised distribution
Should you wish to make radical (or even small) changes to the form designer projects and distribute the modified version, then please feel free to do so, however, you must agree to change all Guids, ClassIds, AppIds, ProgIds, or anything else that would interfere with official binaries located at my website[^].
Demonstration executable
There is a demonstration executable available which demonstrates all the features of the form designer, and is downloadable at the top of this article. In order for the executable to function correctly it is important that the core form designer projects are built up and registered on the system, this is required since the generated ActiveX controls are needed for the executable to run.
Sample Projects
There are a number of sample projects available which make use of the form designer components, and are downloadable at the top of this article. Each project produces the same basic demonstration application, but are all written using a different programming language. The samples currently available were developed using MFC, C#, and Visual Basic.
Help file
There is a help file available which is associated with the form designer components, and is downloadable at the top of this article. Most of the information contained within the help file is pretty much covered by this article, but there is a detailed description of the properties, methods and events of each of the components should you be serious about using them in your own products.
History
I started work on the form designer back in December 2001, by October 2003 I had something which was close to what I had hoped for. There are still lots of nice features which I would like to add, but hopefully these will all come in time.
17 October 2003, Version 1.07 completed.
Acknowledgements
Vladimir Shcherbakov[^] for the property browser[^] article which was very useful for this project.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
