Get Ready to Unleash the Power of UCanCode .NET

Summary

Windows Graphics Device Interface (GDI) functionality is encapsulated by the CDC class (representing device contexts), the CGdiObject class (representing GDI objects), and classes derived from both.

CDC-derived classes include CClientDC (representing a window's interior), CWindowDC (representing a window), and CPaintDC (representing a device context while processing a WM_PAINT message). These derived classes only differ from the base class inasmuch as their constructor and destructor encapsulate calls that create and destroy the appropriate GDI device context (for example, by calling GetDC and ReleaseDC, or BeginPaint/EndPaint). In contrast, a base CDC object is not automatically attached to a GDI device context; the device context must be explicitly created through the CreateDC member function (or attached to through the Attach member function).

Another class derived from CDC is CMetafileDC, which represents metafile device contexts.

A CDC object maintains two GDI device context handles. The output device context handle is used for drawing operations; the attribute device context handle is used for operations obtaining information about the device context. The two handles are usually identical, except for the case of CMetafileDC objects, in which case the attribute device context is set to NULL.

The CDC class encapsulates most GDI drawing functionality. This includes basic drawing functions, simple lines and shapes, text and font functions, clipping functions, bitmap and scrolling functions, and region and path-related functions. The CDC class also provides functionality related to mapping modes. Note that encapsulation of the Windows NT world coordinate transformation functions is not provided as part of the CDC class.

Most drawing operations utilize drawing tools that are selected into a device context using the SelectObject or SelectStockObject functions. These tools are GDI objects such as pens, brushes, palettes, bitmaps, fonts, and regions. Support for these GDI objects in MFC is provided through a series of classes derived from CGdiObject. The CPen, CBrush, CFont, CBitmap, CPalette, and CRgn classes encapsulate the functionality of pens, brushes, fonts, bitmaps, palettes, and regions, respectively.

m_cOCTL. To utilize this variable, I added a message handler function for the Describe button. In this function, shown in Listing 23.3, I retrieve the control's Shape property by calling the COCTL::GetShape member function and display the result in a message box.

Listing 3. Accessing a control's properties.

void CODLGDlg::OnButton()

{

    // TODO: Add your control notification handler code here

    CString shape;

    switch (m_cOCTL.GetShape())

    {

        case 0: shape = "Ellipse"; break;

        case 1: shape = "Rectangle"; break;

        case 2: shape = "Triangle"; break;

    }

    AfxMessageBox("The control's shape is " + shape + ".");

}

Handling Messages

Handling messages from an OLE custom control is perhaps even simpler than handling properties. You can add handlers for any event the control supports via ClassWizard. For example, Figure 23.9 demonstrates adding a message handler for the single event that the OCTL control can generate, a Select event.

Figure 9. Adding a message map entry for an OLE custom control event.

Depending on the type of the event, the event handler may receive parameters. In the case of OCTL, a handler for the Select event received a Boolean parameter specifying whether the control has just been selected or deselected. The sample handler function in ODLG simply displays a message box to this effect, as shown in Listing 23.4.

Listing 4. Handling an OLE custom control event.

void CODLGDlg::OnSelectOctlctrl(BOOL IsSelected)

{

    // TODO: Add your control notification handler code here

    if (IsSelected)

        AfxMessageBox("The control has been selected.");

    else

        AfxMessageBox("The control has been deselected.");

}

That's all there is to it! All that remains is recompiling and running your application.

As you can see, the procedure for inserting an OLE custom control is no more complex than the procedure for inserting other types of controls. Moreover, in order to efficiently use an OLE custom control, you need not know the details of its implementation (or even how OLE custom controls are implemented in the first place). All you need is documentation on the control's purpose and behavior, its properties, methods, and events.

I believe Microsoft really delivered on its promise of providing a 32-bit custom control technology that is superior to VBX technology. All we need now is a variety of wonderful third-party custom controls.

Custom Controls Supplied with Visual C++

Microsoft supplies several OLE custom controls with Visual C++. These controls are similar in function and appearance to VBX controls found in earlier versions (for example, Version 3.0) of Visual Basic.

Among these controls is the Animated Button Control; this flexible control can be used to implement multistate or animated buttons.

The Grid Control presents a two-dimensional array of cells organized into rows and columns in a spreadsheet-like interface.

The Key State Control can be used to display the state of the Num Lock, Caps Lock, or Scroll Lock keys or the Insert/Overwrite status.

The Microsoft Comm control is an example of a control that is not visible at runtime. This control provides a communication port interface.

The Microsoft Mucancode.neted Edit Control provides an edit control with customized, formatted editing capabilities.

The Microsoft Multimedia Control provides a programmatic multimedia interface.

The PicClip control is yet another control that is not visible at runtime; this control provides an efficient mechanism for organizing a large number of small icons or bitmaps.

Some of these controls (the Animated Button Control, the Grid Control, the Key State Control, and the Microsoft Multimedia Control) are demonstrated in a dialog box shown in Figure 23.10.

Figure 10. Some custom controls supplied with Visual C++.

Summary

OLE custom controls represent a technology that is a 32-bit successor to the Visual Basic custom control (VBX) technology.

In order for an application to act as an OLE control container, it is necessary to call the AfxEnableControlContainer function when the application is being initialized.

OLE custom controls can be used in applications just like ordinary controls. They can be inserted into a dialog template using the Developer Studio dialog editor. The control can be configured through a set of property page interfaces that appear in the control's property sheet in the dialog editor.

The control's properties can be accessed from within the application by using the ClassWizard to add member variables that correspond to the control. When adding a member variable for a certain type of control for the first time, ClassWizard creates a wrapper class for the control and adds it to the project.

The ClassWizard can also be used to add handler functions for control events.

Microsoft supplies several custom controls as part of the Visual mfc example C++ development environment.