I looked at Prosise's text, and I also found sample code in the MFC WordPad
application that overides PreCreateWindow, uses the CREATESTRUCT pointer to
build a valid WNDCLASS and then passes it onto AfxRegisterClass.  Works
great - for a window class derived from CFrameWnd.

I then tried the obvious - overriding CWnd::PreCreateWindow() in my
CDialog-derived class, only to find that it is never being called by the
framework!  After a little poking through the MFC source code, it dawned on
me that the dialog window is being created indirectly through the resource
template.

So, does anyone have any good pointers for me?  I'm relatively new to this,
and surely am overlooking something obvious

"Dialog boxes usually belong to a predefined, exclusive window class. The system uses this window class and its
corresponding window procedure for both modal and modeless dialog boxes. When the function is called, it creates
the window for the dialog box, as well as the windows for the controls in the dialog box, then sends selected
messages to the dialog box procedure. While the dialog box is visible, the predefined window procedure manages all
messages, processing some messages and passing others to the dialog box procedure so that the procedure can carry
out tasks. Applications do not have direct access to the predefined window class or window procedure, but they can
use the dialog box template and dialog box procedure to modify the style and behavior of a dialog box."

I think the "usually" there is a little understated.  The basic idea of a dialog box is to standardize a bunch of
behavior.  Instead of using a custom window class and window procedure, dialog boxes use a pre-defined one.  Dialog
boxes then implement a dialog box procedure instead of a window procedure, which the pre-defined window procedure
calls to give the dialog a chance to customize its behavior.  The definition of a dialog box is basically "a window
that uses the predefined dialog window class and window procedure."

Now you still have several options, depending on what you want to customize.  The most obvious suggestion is to
forget about using a custom window class and use the normal dialog customization methods.  The opposite of this
would be to forget about using a dialog based app and create a custom window class that behaves a lot like a dialog
except where you want to modify the behavior.  You might be able to use CFormView directly, or get some ideas on
how to proceed from there.

The correct approach of course depends most on what you want to achieve.  I'd bet you can forget about changing the
window class and achieve what you want with simpler methods of customizing dialogs.

--
______________________________________________________
"And the transistor shall inherit the Earth."
-  A. C. Clarke, 1956
______________________________________________________

Timothy J. Ebben
Levon's Wake, Inc.

Web: www.LevonsWake.com

----- Paul Bunyan - Best Damn Logger There EVER Was!
______________________________________________________