Creating an Application-Defined Window Control
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/28/2008
You can create custom, application-defined window controls to perform tasks that are not supported by predefined controls. Windows Embedded CE provides the following ways to create a custom control:
- Use owner-drawn buttons.
- Use the subclass procedure to produce a custom control.
- Register and implement an application-defined window class.
Buttons have available owner-drawn styles 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 Embedded CE handles the interaction of a user 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 of the 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 parent window of the button 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 window procedure of the button automatically sends the WM_DRAWITEM message to the parent window of the button 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 parent window of the button 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.
You can 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 template for the dialog box. 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 the messages that are sent to it by the parent window or other windows. For example, controls often process the WM_GETDLGCODE message that is 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 send it explicitly to the control by using the SendMessage function or the SendDlgItemMessage function. The numeric value for each message must be unique and must not conflict with the values of other window messages.