Creating an Application-Defined Window Control

You can create custom, application-defined window controls to perform tasks not supported by predefined controls. Windows CE provides the following ways to create a custom control:

Buttons have owner-drawn styles available that direct the control to send a message to the parent window when the control must be drawn. This feature enables you to alter the appearance of a control. For buttons, the owner-drawn style affects how the system draws the entire control.

You can designate buttons as owner-drawn controls by creating them with the appropriate style. When a control has the owner-drawn style, Windows CE handles a user's interaction with the control as usual, performing such tasks as detecting when a user has chosen a button and then notifying the button's owner of the event. However, because the control is owner-drawn, the parent window of the control is responsible for the visual appearance of the control.

When you use the BS_OWNERDRAW style for a button, you assume all responsibility for drawing the button. You cannot use any other button styles with the BS_OWNERDRAW style. When you use an owner-drawn button, you have to trap the WM_DRAWITEM message in the window procedure for the button's parent window and insert the code that erases the background, if necessary, and draws the button.

The WM_DRAWITEM message is not generated by the window manager; it is part of the interface between a button and its owner. When you use a built-in button class, the button's window procedure automatically sends the WM_DRAWITEM message to the button's parent window when the button receives a WM_PAINT message. If you create a new class of button—a button that is not a built-in button—and you want it to support the WM_DRAWITEM message, you must send the WM_DRAWITEM message to the button's parent window when the button needs to be redrawn.

You can use the subclass procedure to create a custom control. The subclass procedure alters selected behaviors of the control by processing those messages that affect the selected behaviors. All other messages pass to the original window procedure for the control.

Create custom controls by registering an application-defined window class and specifying the name of the window class in the CreateWindowEx function or in the dialog box template. The process for registering an application-defined window class for a custom control is the same as for registering a class for an ordinary window. Each class must have a unique name, a corresponding window procedure, and other data.

At a minimum, the window procedure draws the control. If an application uses the control to let a user type information, the window procedure also processes input messages from the keyboard and stylus and sends notification messages to the parent window. In addition, if the control supports control messages, the window procedure processes messages sent to it by the parent window or other windows. For example, controls often process the WM_GETDLGCODE message sent by dialog boxes to direct a dialog box to process keyboard input in a specified way.

Because an application-defined control message is specific to the designated control, you must explicitly send it to the control by using the SendMessage or SendDlgItemMessage function. The numeric value for each message must be unique and must not conflict with the values of other window messages.