Microsoft KB Archive/59737

INF: Preventing Dialog Controls From Overwriting Size Border PSS ID Number: Q59737 Article last modified on 09-06-1991 PSS database name: P_PresMan

1.10 1.21

OS/2

Summary:

The following information describes how to prevent the application controls within a window (for example, fields, radio groups, and so on) from overwriting the frame controls.

The nested frame and client windows that result from a call to WinCreateStdWindow were designed to resolve this type of problem. By clipping the drawing to the client’s reduced size, the border of the frame is protected. A dialog box is a frame window; however, it does not have a client window. The various controls on the dialog box are the direct children of the frame. As is noted above, this causes problems when the controls overwrite the size border. By one interpretation, allowing a dialog box to have a sizing border is considered to be an overgeneralization of its original design.

There is a clean solution to this problem; however, it is fairly involved. In the DLGTEMPLATE section of the .RC file, rather than specifying DIALOG, specify FRAME and give it an ID of FID_CLIENT. This frame will NOT have a sizing border, minimum/maximum buttons, and so on. Instead, a frame will be dynamically created with these features in the programmer’s C code. Then when it is time to show the dialog box, the frame must be loaded from the resource data and set into the frame that was created dynamically. In this way, there will be a “frame within a frame,” with the inner frame also being a “client window.” This inner frame will then provide the proper clipping, and the outer frame will provide sizing, movement, minimizing, and so on.

It is necessary to have the client window be of the frame class to get the default dialog box behavior (tabbing between groups, arrow key movement within a group, and so on). There are just a few modifications that must be made in the window procedure to get this “frame within a frame” to act like a proper dialog box. The programmer must make sure that the client clears the background on paint messages. And the parent must also be dismissed on a WM_CLOSE message [WinDefDlgProc dismisses the dialog itself – in this case, the inner frame]. Finally, the buttons do not post close messages automatically; therefore, the programmer must handle this task in their code.

All of this functionality is demonstrated in a sample application in a file named FRAMEDLG in the Software/Data Library. FRAMEDLG can be found in the Software/Data Library by searching on the word FRAMEDLG, the Q number of this article, or S12543. FRAMEDLG was archived using the PKware file-compression utility.

FRAMEDLG contains the files BASE.C and BASE.RC. Please see the last two functions in BASE.C and the dialogtemplate in BASE.RC for more detailed information on this topic.

Copyright Microsoft Corporation 1991.