The VALUESET statement creates a value-set control within the dialog window. This control lets a user select one choice from a group of mutually exclusive choices. The VALUESET statement defines the identifier, coordinates, dimensions, and attributes of a value-set control. The predefined class for this control is WC_VALUESET. If you do not specify a style, the default style is WS_TABSTOP and WS_VISIBLE. The VALUESET statement is used only in a DIALOG or WINDOW statement.
Example
This example creates a value-set control at position (40, 40) within the dialog window. The value set control has a width of 220 character and a height of 20 character units. Its resource ID is 302. The style specification VS_ICON creates a control to show items in icon form. The default styles WS_TABSTOP and WS_VISIBLE are both in effect, though only WS_TABSTOP is specified.
#define IDC_VALUESET 302
#define IDD_VALUESETDLG 501
DIALOG "Value set", IDD_VALUESETDLG, 11, 11, 260, 240, FS_NOBYTEALIGN |
WS_VISIBLE, FCF_SYSMENU | FCF_TITLEBAR
BEGIN
VALUESET IDC_VALUESET, 40, 40, 220, 160, VS_ICON | WS_TABSTOP
END
A dialog template can be in either of the following:
The dialog template uses device-independent dialog units for the coordinate system that define the layout of controls in the dialog box.
A dialog unit is expressed in terms of the default standard character size, which can vary from device to device. You do not need to put code in your application to reformat the dialog box when displaying it on different devices. (Dialogs might need editing if a different system font is loaded.) A horizontal dialog unit is 0.25 of the standard character size. A vertical dialog unit is 0.125 of the standard character size. Dialog units are expressed as offsets from the origin (lower-left corner) of the dialog box.
A dialog template is a general structure. It could be termed a window template, because you can use it to define any window in an application. If you prefer, use the statement WINDOWTEMPLATE instead of DLGTEMPLATE, because it is functionally identical. This could reduce the initialization phase of the application to registering the application window classes and calling WinLoadDlg to load the template.
If you use the Dialog Editor to define a standard window, you will have to edit the resulting .DLG file to ensure that you have a client window and the required parent-child relationships. You will also have to use WinLoadMenu in your application, to create a menu bar for the window, because you cannot create menus using the Dialog Editor.
The .RES file is an object-format compiled version of the .DLG file, created when the Dialog Editor compiles the dialogs. The Dialog Editor uses the .RES file as input on any subsequent edit of the same dialog. This means that, if you use a text editor to fine-tune a .DLG file, and you want subsequently to re-edit the dialog using the Dialog Editor, you must first use the Resource Compiler to generate a new .RES file from the .DLG file.
Your application can use either the .RES file output by the Dialog Editor or a .RES file created from the .DLG file and the other resources. If your application uses the .DLG file, it must be included by the resource script file of your application.
The rcinclude statement includes the .DLG file created by the Dialog Editor; for example:
rcinclude dbe.dlg /* Includes .DLG file */
The corresponding .H file created by the Dialog Editor must also be included in the .RC file.
Using OS/2-defined control windows, OS/2 draws and operates the controls specified in the resource file for your application. Controls are windows and can be used within any other window.