home > Computers & Technology > GUI Application Development > Selecting Custom Controls

Selecting Custom Controls

by Juan Ramón Acosta

April 2nd, 1996

Background

A custom control is a special format of object file used to add additional features and functionality to the user interface of the Windows (95/NT) operating system. A custom control can be: a variation on an existing Windows dialog box control or a totally new category of control. For example, a text box that accepts numeric values using the mask (999) 999-9999.

Since Windows 3.0 was commercialized, developers started writing custom controls to facilitate the development of applications for Windows. At the beginning those controls where implemented as dynamic link libraries (DLLs) that were linked to the application. Few years later, along with Visual Basic, a new type of custom control was defined, VBX. The idea behind a VBX was to establish a standard for custom controls and reduce the effort required to develop applications for Windows.

Today, many custom control providers are worry rewriting their current products as OLE custom controls (OCXs) to face the introduction of Windows 95. OCXs are the replacement for VBXs.

Selection Guidelines

What type of custom controls shall we have to select for the project? Shall we use VBXs or OCXs or Libraries of Custom Controls?

In order to answer those questions we have to consider a couple of things. First, we have to keep in mind that the front-end will be deployed initially on Windows(95/NT) and short after on X/Motif, so that, it is important the custom controls selected are portable. Second, it is required the front-end to be high performance.

How to Warranty Portability

There are several ways to make custom controls portable:

  • Do not use VBXs.
  • License custom control’s source code- Many vendors currently sell and support the source code along with their custom control libraries for a reasonable price. The advantage of getting source code is: the library can be easily ported to X/Motif when using a tool that supports the Windows(16/32) API. The port is reduced to recompile the library on UNIX.
  • Although, to warranty a smooth migration, we have be sure: a) the library was originally written using the Windows API, b) avoid any kind of source code modification, but if necessary do it with care.
  • License MFC extensions- As long as Visual C++ has become the development environment of choice, MFC has become the class framework of choice to build applications for Windows. Therefore, a considerable number of people have created extensions to the MFC. Those extensions are build from the ground up using MFC. Along with extension libraries (AFXDLLs) source code is given and immediately we gain the benefits mentioned in the previous option.
  • Since all the custom controls provided by MFC’s extensions make use of the Windows API and MFC, their migration is simple.
  • Buy the X/Motif versions- Just a few custom controls for windows that had been ported to UNIX, they are implemented mostly with X/Motif API, they are expensive and do not provide source code.
  • Buy or develop OCXs- We can develop our own custom controls. It will be time consuming and it will add a lot risk to the project given the fact that OCXs technology is on its early stage. Besides there are not people in the project with experience on this ground. To buy OCXs would be ideal, but the current tools in he market does not fully support them. It will be too expensive and almost impossible to get the source code for the OCXs we can occupy.

In our case the best three options are: option one in combination with option two or three.

How to Warranty High Performance
  • Evaluate the custom control’s performance by conducting load and stress tests with it. Performance will be monitored and quantified based on: the number of dynamic updates the control is able to handle before it starts slowing down and the time it takes to render data on the screen.
  • Analyze the figures obtained from testing, try to increase performance by following the vendor’s recommendations or if we own the source code try to modify it to improve it.
  • Run performance tests on each platform supported once the custom control had been ported.
  • Avoid the usage of complex OCXs due to the low performance OLE2.0 is characterized today.
  • Practice good Windows programming techniques, like the mentioned in various books about Windows programming.

back to top


created by: dadasdesign

last update: Thursday, October 07, 2004

home | about myself | comp&technology | favorite sites