Currently, to create a dialog box driven application, you have many choices. I'll list the most popular methods:. Each of the mentioned methods above have their pros and cons, but that's beyond the scope of this article.
Now as promised, here's a small overview on how each of the mechanisms work. If you are not using the dialog designer, you will have to create the controls in the code by calling the CreateWindow function.
As for MFC dialog based applications, the concept is similar, however everything is wrapped into neat classes. So, all you have to do is:. What is a dialog template? It is a structure that defines the styles and dimensions of a given dialog. There is an extended version of this structure that renders the latter obsolete. That is to say its purpose is functional rather than aesthetic.
Anything of an aestheitic nature is better handled by the metrics struct passed in. Here is a more developed metrics struct that we will use for the examples that follow;. This puts it there for all to see including derived controls that want to adopt the colours of specific control types. However this method of handling is limited in discrimination to the control types enumerated by nCtlColor. Painted controls.
I have always felt a bit uncomfortable about creating a STATIC control window to sit on a dialog and give an impression of a label painted straight onto the dialog. Why not just paint a label straight onto the dialog? For various reasons I've been doing this for years. Labels are easy, buttons aren't too much trouble and I have done nice list boxes. Not edit boxes though, at that point the edit control window is packed with functionality that you don't want to replicate and as it is already sitting there as part of Windows, the overhead of creating a window is more than justified.
Nevertheless a typical dialog is plastered with many control windows that could be just painted onto the dialog and in some cases it would make more sense.
Such painted windowless controls are supported and it is relatively easy to define them. Also used is a class derived from PaintedLabel :. Other painted controls included in the library are SpacerControl which is a hidden reference frame on which other controls can be hung it has no code , GroupBox which is a replacement for the Windows group box and PaintedTabFrame which you have to use instead of a Windows tab control.
The code for these can be found at the foot of autodlg. The x,y coordinates in this case are with respect to your control, not the dialog. For most painted controls, implementing those two handlers is enough. However there are more resources available in the design of painted controls with more complexity such as PaintedTabFrame :.
You may also implement void OnControlCreated which will be called after the control has been created and OnDialogCreated which will be called after all controls on the dialog have been created. PaintedTabFrame needs the latter to adjust to its content which may expand as it is created. You also have access to and can override the generic methods provided for all controls.
For instance PaintedTabFrame overrides invalidate , size , move and show. That is all there is to know about designing painted controls as far as library support is concerned.
To get an idea of how to go about it, study the source code of the examples listed above. A more complex example. You enter your access code, select a day of the week and a time of day, view the report and then launch an imaginary process in either a modal or modeless dialog. This section will show all of its code. Comments are used to clarify the working of the control and bold is used here to highlight anything introduced here for the first time and explained in more detail.
In this case the class definition passes three template parameters into the autodlg::dialog base class. This is the full list of template parameters it can take:. We just need a string to store some text. You would normally use the CString of MFC or WTL or std::string but I didn't want any other library dependancies in the example so I used the very basic dynamic string that comes with this library.
That is, it is the dialog that we defined earlier. The dialog will display at the size specified in the layout or its own initial size, whichever is greater. This means you don't have to be exactly precise with the size you specify in the layout. Although this means that you could specify a zero size and it will still display, that would not allow you to place any controls to the right or underneath it in your layout. You should specify a layout size that is somewhere near the dialogs own initial display size and use that as a basis for how many controls can fit to its right or under it.
The first control also has a label of type BannerLabel , the variant of PaintedLabel mentioned in the section on Painted Controls. The second control is called edtUser because it originally was an edit with a label but the edit is never edited so it might as well be a label as well. So there you have it; a label displaying a value with an accompanying label. The third control is a SpacerContro l.
This is invisible and has two functions: a reference for other controls and it can be made expandable so controls to the right or below are pushed to the right or down. This means it will expand horizontally as the dialog is resized so it continues to run right across the dialog.
The last control is of type GroupBox. This is a PaintedControl that performs the same function as a windows Group Box. It is only a small detail but it can make Win 32 programming almost as readable as using the methods of control class wrappers.
So we hide it. This is the handler for any notification from the embedded EnterCodeDlg. No parent notifications were designed into EnterCodeDlg but because it is embedded as a child, the EndDialog calls in the OK and Cancel buttons will send notifications instead of closing the dialog. UpdateReport is called whenever the day of week of time of day selection changes. It updates what is displayed in edtReport and also detrmines if btnModal and btnModeless should be enabled.
This is not part of the functioning of this dialog. It is there in polite anticipation of it being embedded within another dialog.
It is the event the host dialog most likely might need. The dialog launched by btnModal and btnModeless uses a variety of painted controls as well as a windows progress control:. In this case, painted controls were the most straightforword way of getting the behaviour I wanted. The Go button has to be pressed in a very deliberate way, the Stop button goes off as soon as you touch it and the smiley face has its own special behaviour.
Tabbed dialogs. One thing you won't be able to do with these dialogs is use them in standard windows tab controls. This is because standard windows tab controls use dialog templates and these dialogs don't have any. Therefore a windowless PaintedTabFrame control is provided. It is called PaintedTabFrame because it is not a window that owns the tab content. It simply frames the tab content and controls which is visible.
The content is directly owned by the host dialog. Its use is as follows:. Here is it showing the most populous tab:. In this case the host dialog TabbedDlg is dedicated to displaying tabSelect the PaintedTabFrame and its contents because that is what you usually want, but it doesn't have to be. Unlike window tab controls, all of the tabs are created together as members of the host dialog, rather than created as each tab is selected.
As we will see, this greatly facilitates any coding the host dialog may require. As it stands the tab frame allows you to tab wherever you like quite usually just what you want regardless of whether you have entered a valid code or selected a day and time period. So lets start to tie things down so you have to follow some sort of proper procedure starting with OnInitDialog :.
Having got a correct code we now want to display the next tab, dlgSelectData, but that in turn displays its own dlgEnterCode. There are three types of styles: window styles, class styles and extended styles. Window styles include information such as bits to indicate if a control is disabled, starts a group or if it is a tab stop.
Class styles are specific to the control class. For example, for a combobox, one class style indicates whether the control is a list, a dropdown, or an editable dropdown.
These bit positions are shared across classes but their meaning will be different. Finally, extended styles apply to the window and the class. The identifier or ID is used to access the control within a dialog page. This is a bit value signed or unsigned where -1 has the meaning of no specific control ID. The value -1 is frequently used for controls, such as legends, that do not need to be addressed. This can be either the ordinal value of a predefined system class or a string that specifies the name of a registered window class.
Depending on the class, the value may be ignored or set the initial state of a control. For example, a legend normally has the text value set. Every dialog box template contains measurements that specify the position, width, and height of the dialog box and the controls it contains. These measurements are device independent such that a script can use a single template to create the same dialog box for all types of display devices.
This ensures that a dialog box will have the same proportions and appearance on all screens despite differing resolutions and aspect ratios between screens. The measurements in a dialog box template are specified in dialog template units. Dialog units are not necessarily scaled the same vertically and horizontally. By default, Legato will center dialogs on the application which the dialog appears. The template may specify the initial coordinates of the upper left corner of the dialog box.
The system sets this initial position when creating the dialog box. The dialog template should specify a dialog box width and height that does not exceed the width and height of the screen and ensures that all controls are within the page of the dialog box. Privacy policy. Defines the dimensions and style of a dialog box.
The style of the dialog box. The font data begins on the WORD boundary that follows the title array. The font data specifies a bit point size value and a Unicode font name string. If possible, the system creates a font according to the specified values. The extended styles for a window. This member is not used to create dialog boxes, but applications that use dialog box templates can use it to create other types of windows.
0コメント