Create a dynamic user interface using a CWnd free pool

Introduced

This article presents a set of classes that can be used to dynamically create a UI. The code is a CWnd inherited control that concentrates on a free pool using the manager, which helps us reduce the use of GDI resources in a particular UI scenario. To demonstrate these classes in the run, I've provided an example of an MDI application here, and it just lets you open the XML file. Each XML file defines the layout and UI control properties for a single MDI child form. Although the code is written in VC6, the sample project can also be converted to VS 2003 and VS 2005 projects.

UI Scene

Here are two common UI scenarios that might benefit from the concept of a free pool. The first example is a network management application that allows an operator to control a number of different types of remote devices. Each device has a set of parameters that can be read or set almost in real time. One possible UI pattern for this type of application is that your basic MDI framework allows you to open an MDI child form to control a single device instance. Because each device may have numerous (10 or even hundreds) of parameters, the UI controls in each MDI child (or device) form are organized into logical groupings with the labels shown in the following illustration.

A typical way to implement the UI for each device type is to create a different dialog box or property page for the control for each label. This method is simple to implement but it does not work well. Consider a situation where you need to support a device type with 200 parameters. Assume that each label in a device form can provide a layout for a control with up to 20 parameters. Therefore, you need to create 10 labels or dialog boxes. Now, if you think that each parameter may need to be accompanied by its self-describing text label, the number of UI controls required to represent the full device may be more than 400. Also, for specific parameters, UI controls may not be as simple as your basic CButton or cedit. It may be a third-party-measured ActiveX control (which you must use in your project), or a cluster similar to the Windows Forms user control. Therefore, the cost of GDI resources that must implement a single device form can be high and become a limiting factor when operators need to open many of these device forms at the same time.

The second example is the Options dialog box (for example, the Options dialog box in VS2005). The representative of this type of dialog box contains a tree view on the left-hand side and a set of UI controls on the right. Each time the selection in the tree view changes, the right hand group of controls changes dynamically. This UI scenario is actually very similar to the first example of a label device constant form. The main differences are in the selection and grouping mechanisms (for example, the tree view selects the corresponding label selection).

CWnd Free Pool

Removing the need for different dialog boxes or property pages is one way to reduce the resource requirements of the label device form. The UI controls are hidden or displayed by using only one dialog box and implementing a mechanism, depending on which tab is currently selected. The same number of UI controls need to be created, but we save the controls as many as we need in the dialog box.

If we realize that the same type of UI controls are often displayed in multiple tags, you can get a lot more savings in resource usage. In other words, instead of hiding controls when the label selection changes, we can store hidden controls in the free pool or cache so that they can be reused when converting to a different label. This allows us to select the reuse UI control instance through the tag. For example, if a tag uses a CButton and another tag to use a CButton, for both labels it should just create a CButton instance and use the same UI instance. In this way, the number of UI controls required for each device form can be quite large. As an example of the best case scenario, consider a device with 10 parameter groups (tags) and 200 parameters, each of which is represented by a trackbar (slider) control. If we also want to match each trackbar with a corresponding text label control, then a total of 400 UI controls are required to be implemented using a typical multiple dialog box. However, if we reuse trackbar and label controls from one label to another, the device form will require at least 20 trackbar and 20 label controls, which can be 10 times times less resource usage.

To implement the reuse mechanism, we first define a Cwndfreepool class that simply saves the idle and available CWnd instance track. Each CWnd referenced in the pool is matched with a string identifying the CWnd corresponding to the type of the UI control. For example, the "button" type string identity pairing CWnd is actually a CButton instance (created in Bs_pushbutton style). In addition to MFC built-in controls such as CButton, a free pool can reference ActiveX controls because Visual Studio can generate an MFC wrapper class for ActiveX controls that inherit from CWnd. The public interface for the Cwndfreepool class is shown below.

// CWndFreePool保持引用到已被创建但没有使用的（隐藏）的CWnds。
//该池包括仍在池中的CWnds的所有者并在其析构体删除它们中。
class CWndFreePool
{
　　 public:
　　 //构造器/析构器
　　 CWndFreePool();
　　 ~CWndFreePool();
　　 // Public 方法。
　　 CWnd* GetWnd(const CString& strType);
　　 voidAddWnd(const CString& strType, CWnd* pWnd);
};