Controls and the Dialog Editor
A dialog box is a window in which the user interacts with the program by means of standard interface devices known as controls. These include (but this is not an exhaustive list)
· edit boxes
· static text boxes
· push buttons
· radio buttons
· check boxes
· scroll bars and sliders
· list boxes
· combo boxes
· spin controls
To start with, we'll look at examples of each of these and study what their purposes are. Here's an example, snapped from Word:
This uses a listbox and three pushbuttons. At the bottom there is a checkbox. The checkbox can be checked, or not. The list box is
used to select ONE of the available options. The OK button and cancel button, as in almost all dialogs, close the dialog box and either cause the choices to take effect, or be discarded. In this dialog there is also a Default button that causes them to become the default choices in the future.
Push buttons in general are used to invoke actions. That is, to make something happen, as opposed to just building up some data selections. Generally you use other controls to select or enter some data and then a push button to do something with the data.
Here's an example showing some radio buttons and an edit box:
Radio Buttons and Check Boxes compared
Radio buttons are used when the user has to choose one of several items, and is not allowed to select more than one.
Check boxes are used to select options, where the options can be selected independently, so you can choose more than one, or none.
The checkbox on the previous slide (Update Automatically) could be done with TWO radio buttons:
· Update Automatically
· Don't Update Automatically
of which only one could be selected. But a checkbox is better.
The Footnote/Endnote choice above cannot be reduced to a checkbox, since the alternatives need to be communicated.
Edit boxes and List boxes compared
Edit boxes are used to allow entry of possibly unanticipated text.
If the possible choices come from a fixed list, use a list box. You do not have to know the list at compile time--the program can add items to the list box at run time.
Combo boxes
If you can anticipate some possible or likely choices, but unanticipated entries can still be typed in legally, use a combo box. Here's an example:
You can type in a new filename, or select a recent file from the
drop-down list.
Combo boxes should not be used where the list of choices is restricted and known. Here's an example of misuse in an old version of Microsoft Word:
You can type in 13 for the point size, but (in an old version of Word) you can't actually get 13-point type. It came out 14-point.
The current version of Word does allow 13-point type, and any size you type in. But if, as used to be the case, the possible point sizes are known in advance, it merely misleads the user to let them type in 13.
A similar problem still exists with the Font Style box. If you type in "Greek" (or anything but the four legal choices) it will give you an error message. A list boxes should have been used instead of a combo box, since there are exactly four legal choices.
Static Text Boxes
A static text box is a small window that (usually but not always) contains some text.
For example, the text "File name" is in a static text box, and the
text "Files of type" is in another static text box. You do not see the boundaries of these text boxes because their background colors are the same as the dialog's background color and they have no visible border.
The text is "static” in the sense that the user of the program cannot change it. Very often it is fixed at compile time. However, it is possible to set it dynamically, under program control, at run-time. This is not at all uncommon.
Programmers should realize that static text is under their run-time control.
Using Static Text Boxes for Pictures
The white box after "Preview" is really a static text box, this time with a white brackground. It is used to draw a sample of the font in the selected style and size. Any Windows graphics can be used to draw in a static text box (if the programmer knows how).
This dialog illustrates spin controls.
This dialog shows an edit box with a spin control, and a slider that communicates with the edit box. When you change the contents of the edit box, the slider moves, and vice-versa, when you move the slider, it changes the number in the edit box.
A slider can be used by itself, of course, as in the volume control of an audio player, but in this course you will learn how to make a slider communicate with other controls while the dialog box is running.
Controls are windows
It is very important to understand that each control is really a window.
A list box is a window.
A button is a window.
An edit box is a window.
A radio button is a window.
A check box is window.
A static text box is a window.
Etc. for all the other controls.
There are pre-defined window procedures for each of these types of windows. In MFC, there are classes derived from CWnd, such as CButton, etc. You should look in the class hierarchy diagram
(find it in the online documentation) and see the inheritance structure of these classes.
Generally, any window can have a parent window, in which case it is a child window of its parent. A top-level window has no parent (technically its parent is the desktop, which is indicated by a NULL parent window). In MFC, the frame window is a top-level window, and your view-class window is a child window of the frame window.
Dialog controls are child windows of their parent, which is the dialog box window.
Designing Dialog Boxes versus Programming Dialog Boxes
InWindows programming, these are two different steps. The visual appearance of a dialog box is one thing, and the code that makes it work is another thing.
The visual appearance is managed using the Dialog Editor in Visual C++. The end result of this is a few lines of script in the .rc file, as we have seen already for menus. You could write these scripts directly (in a text editor), and that was how it was originally done. Here's a sample dialog and the code in the resource script that describes it. You don't have to pay attention to the script--the point is that SOME script describes the dialog and that the script is what the compiler uses to produce your program.
The script is the only end product of the visual environment in the Dialog Editor.
CONFIRMCLOSEDIALOG DIALOG DISCARDABLE 6, 15, 152, 88
STYLE DS_MODALFRAME | WS_POPUP | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Mathpert"
FONT 8, "MS Sans Serif"
BEGIN
LTEXT "Close this calculation?",
IDC_CLOSEPROMPT,31,6,103,15
DEFPUSHBUTTON "OK",IDOK,34,27,34,19
PUSHBUTTON "Cancel",IDCANCEL,84,27,34,19
CONTROL "Don't ask this question in the future.", IDC_CONFIRMOFF,
"Button",BS_AUTOCHECKBOX |
WS_TABSTOP,10,49,133,12
LTEXT "If you turn off confirmation here, you can turn it back on
from the Options menu.",
IDC_CLOSEADVICE,11,67,135,17
ICON 32514,-1,7,5,18,20
END
The reason it was awkward to write programs this way should be apparent. You have to specify the coordinates of the buttons, etc. yourself. If you don't like the result, you have to edit and recompile and relink before you can see the effect of your changes! What a slow and painful process.
To start using the dialog editor, make a project, and on the page where you previously chose SDI or MDI, take the choice Dialog Based.
This means that the main window of your application will be a dialog box. You will not have an OnDraw function to write because Windows will draw the controls on your dialog box. After clicking Finish, the Dialog Editor is opened automatically:
The toolbar at the left has icons for various controls. You drag and drop them to the desired positions on your dialog. The initial text "TODO:..." is a static text box. Click once on it (or any control) to select it (while the select tool, the arrow, is selected in the toolbar). Then you can delete it by pressing the Del key. Tooltips will show you which icon corresponds to which control. You can also place controls by clicking the icon in the toolbar and then clicking in the dialog, instead of drag-and-drop, but usually drag-and-drop is easier.
After dragging a button onto the dialog you will see
Now right-click the button and choose Properties from the context menu. Scroll down to the bottom of the list. You will then see:
On the property page, you can change the caption of the button and its ID number. Each control needs an ID number, which is fixed at compile time. These are given by integers, but these integers are #-defined in resource.h, and you NEVER refer to the actual values, but only to identifiers such as IDC_PRINT, IDOK, IDCANCEL, etc. The caption and the identifier should be chosen together so that you can recognize your button in code by either. For example, a caption of Push Me and an identifier IDC_PUSHME. Just take Visual Studio’s suggestion for the prefix, and change the last part to match the caption. The prefixes tell generally what kind of object is being identified. Here the “C” is for “control”.
Now you see your button in the dialog editor:
and you can also run the program and see the button.
You should experiment (before Friday's lab) in placing various controls on a dialog in this way. Right-click each control and look at the properties dialog. Use only the controls in the top third of the toolbar—down to Static Text. We will get to the rest of them later.