|
Purpose |
Add a custom control to a DDT dialog. |
|
Syntax |
CONTROL ADD classname$, hDlg, id&, txt$, x, y, xx, yy [, [style&] [, [exstyle&]]] [[,] CALL callback] |
|
classname$ |
A registered custom control or common control class name, for example, "MSCTLS_STATUSBAR32", etc. classname$ may be a string expression, quoted string literal, or a string equate. |
|
hDlg |
Handle of the dialog in which the control will be created. |
|
id& |
Unique identifier for the control. Equates are recommended for clarity of the source code. |
|
txt$ |
Text to be displayed in the control, if any. txt$
may be a string expression,
|
|
x, y |
|
|
xx |
Integral expression, variable, or numeric literal value, specifying the width of the control. The width is given in the same terms (pixels or dialog units) as the parent dialog. |
|
yy |
Integral expression, variable, or numeric literal value, specifying the height of the control The height is given in the same terms (pixels or dialog units) as the parent dialog.. |
|
style& |
Primary style of the custom control. There are no default style values for a custom control. Many standard Windows common controls require the %WS_CHILD and %WS_VISIBLE styles to be explicitly specified, or the control may not be visible or function correctly. Please consult the control's documentation for information on its primary and extended styles. |
|
exstyle& |
Extended style of the custom control. As with style& above, there are no default extended style values for a custom control - the statement should explicitly include all required primary and extended styles for the control. |
|
callback |
Optional name of a Callback Function that receives all %WM_COMMAND and %WM_NOTIFY messages for the custom control. See the #MESSAGES metastatement to choose which messages will be received. If a callback for the control is not designated, you must create a dialog Callback Function to process messages from your control. If the control Callback Function processes a message, it should return TRUE (non-zero) to prevent the message being passed unnecessarily to the dialog callback (if one exists). The dialog callback should also return TRUE if the notification message is processed by that Callback Function. Otherwise, the messages are handled by the DDT engine. |
|
Remarks |
When the user interacts with the control, a message is sent to the designated Callback Function. If there is no Callback Function designated, the message is sent to the callback for the dialog. The style& and exstyle& values are dependent on the type of custom control or common control being used. The notification messages sent to your callback are also dependent on the type of custom control or common control being used. When the Callback Function receives a %WM_COMMAND message, the identity of the control sending the message can be found with the CB.CTL function. Use the CB.CTLMSG function to retrieve the notification message value in your callback. However, many Windows common controls send %WM_NOTIFY messages (to the parent dialog's callback, not the control callback) rather than the more conventional %WM_COMMAND messages. In such cases, the meaning of the message parameters CB.WPARAM and CB.LPARAM will vary according to the type of notification message being processed. |
|
Restrictions |
Custom controls may require special handling other than the DDT generic functions (CONTROL SET COLOR, CONTROL SET FONT, etc.). Consult the controls documentation for information. |
|
See also |
#MESSAGES, Dynamic Dialog Tools, CONTROL HANDLE, CONTROL SEND, |