Win32: CreateDialog instead of multiple calls to CreateWindow - any downsides?

Question

I'm currently working on a Win32 program which requires a main window containing many child window controls - buttons, listviews and so on. I believe the standard way to build such a window is to first call CreateWindow for the main window, then again for each of the controls.

As an easier option, I'm considering designing the main window using the resource editor's dialog box designer, then using CreateDialog to build the main window in one go.

By using a CLASS statement in the dialog box template, I should be able to get the main window to use a custom window class (and hence a custom window procedure) and thus avoid the window having any dialog-like behaviour. An example of this technique can be found in Charles Petzold's "Programming Windows": the HEXCALC program in chapter 11.

Are there any downsides to creating my main window in this way? If so, what are they? If not, why is this approach rarely used?

Cryptogam

Answer 1

The only downside of CreateDialog I know of (as compared to repeated CreateWindow, not talking about some heavyweight framework, just Win32 vs Win32) is that dialog resources position child windows using dialog units. So the layout is dependent not only on DPI, but also on the user's theme settings (choice and size of font).

If any of your controls need to have fixed sizes in terms of pixels, you won't be happy with the dialog-provided positioning and will need to go through and move all the child windows after the fact.

So yes, you can use CreateDialog as a shortcut for creating a bunch of windows with specified classes and styles. But no, you can't do your layout in the dialog editor.

OTOH, you could store the DLU <-> pixel conversion used on your design machine, and then learn enough about parsing the DIALOG resource internal format to pull out the positioning information, then convert to pixels and correct the positioning in more automated fashion.

Sherronsherry

The conversion of dialog units to pixels is actually rather simple. See the MapDialogRect function: msdn.microsoft.com/en-us/library/windows/desktop/… – Untenable

Answer 2

You don't get control of your main window message loop - the dialog manager handles it for you. On the other hand, the dialog manager handles keyboard accelerators, tab ordering and a number of other effects.

You'd be surprised what you can do with a standard dialog box - the windows volume control is implemented with about four different dialog boxes - it has a frame dialog box which in turn host hosts a tray window which in turn holds volume control dialog boxes, one for each app volume.

Chantel

"You don't get control of your main window message loop" - are you sure? I know this is the case for DialogBox, but for CreateDialog I thought you could (and indeed must) make use of the usual message pump. – Cryptogam

My bad, you're right that with a modeless dialog box you can control it. But you need to insert a call to IsDialogMessage to ensure that controls get their messages. – Chantel

@Larry Modeless dialog box does not have a message pump. In fact that is one of the differences between a modeless dialog box and a modal dialog box. :-) – Recrudescence

Answer 3

You will be able to have the full control over your window, even if it was created with CreateDialog.

Normally, when you create your own window (of your class), the window procedure used is the one that you registered with the class. OTOH windows created via CreateDialog will have the dialog standard window procedure (DefDlgProc), which will mostly invoke your supplied "dialog handler".

If you want to have full control of all the messages you may replace the window proc of the newly created window right after its creation. Just call SetWindowLongPtr with GWLP_WNDPROC parameter. Still, you may do the auto processing of some dialog-specific things by calling IsDialogMessage within your procedure.

Valera

Using GWLP_WNDPROC in this way seems to be similar to the technique of using a CLASS statement in the dialog box template. Despite the apparent advantages of these approaches (relating to ease of development), they don't seem to be used very often. Do you know why that might be? – Cryptogam

@Paul Baker: my guess: (1) not everybody knows (or dares to) modify the resource file directly without using the MSVC wizard, (2) nobody cares since the differences are marginal, (3) you may want theoretically the DefDlgProc to do some sort of an initializations (such as setting the focus to the first control with WS_TABSTOP flag). – Valera

Answer 4

There is no downside whatsoever.

Why is it rarely used? Because:

• People normally use DialogBox instead, since that is easier for simpler cases.

• For more complex cases, people use things like MFC or ATL (or some external library like GTk or Qt), and don't bother with native Win32 graphics.

Gyrostatics

Answer 5

There are no downsides using the Windows SDK, internally libraries like MFC use the Windows SDK .

People tend to use libraries like MFC over Windows SDK, as libaries have the readymade stuff. However Windows SDK calls are faster than library calls, so in some situations developers call Windows SDK directly .

CButton btnOk ;
btnOK.Create(_T("Press Me"), WS_CHILD|WS_VISIBLE|BS_PUSHBUTTON,CRect(100,100,300,300), pParentWnd, 1);

is similar to the following code ,

HWND hWnd = CreateWindow("BUTTON","Press Me",WS_CHILD|WS_POPUP|BS_DEFPUSHBUTTON,100,100,300,300,NULL,NULL,GetModuleHandle(NULL),NULL);
ShowWindow(hWnd,SW_SHOW);

Recrudescence

That's so misleading. WS_VISIBLE works just fine with CreateWindow. UpdateWindow isn't needed either. The convenience of MFC is in message maps and automatic subclassing, not button creation. – Sherronsherry

@Ben, Thanks. I was showing an example in MFC and Windows SDK. Though I dont agree about automatic subclassing. Subclassing does not come built in, whereas message maps and message reflection does. – Recrudescence

Subclassing is built in to MFC. – Sherronsherry