Destroying a window in InitDialog?

Hannes Gräuler

unread,

Jul 9, 2001, 5:35:12 AM7/9/01

to

This is easy to answer I hope.

I want my Dialog window destroyed because the
Initialization failed in InitDialog().. But just using
DestroyWindow() ends in an access violation..

Thanks

Franz Grassl

unread,

Jul 9, 2001, 6:32:11 AM7/9/01

to

try to send a WM_DESTROY windows message like:
::PostMessage( hWnd, WM_DESTROY, 0, 0)

Hannes Gräuler <hangr....@gmx.de> schrieb in im Newsbeitrag:
9ibtrl$h7u$07$1...@news.t-online.com...

Joseph M. Newcomer

unread,

Jul 12, 2001, 7:23:01 PM7/12/01

to

First, don't use ::PostMessage, just call PostMessage. Using the raw
API to post a message to the dialog from the OnInitDialog handler is
silly. Furthermore, doing a PostMessage of WM_DESTROY does nothing at
all useful; WM_DESTROY is a message that is sent *during* the destroy
process, not one which initiates destruction. Sending the message
explicitly will simply confuse the world.

Actually, I'd be inclined to call CDialog::OnCancel, since you don't
call DestroyWindow on modal dialogs.

Note that saying "ends in an access violation" isn't terribly
informative; you should be running under the debugger and be able to
determine what was going on. But I think that calling DestroyWindow on
a modal dialog is the real cause here.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www3.pgh.net/~newcomer
MVP Tips: http://www3.pgh.net/~newcomer/mvp_tips.htm

Jeff Partch

unread,

Jul 12, 2001, 7:26:39 PM7/12/01

to

Why not call EndDialog(-1) and return FALSE?

Jeff...
--
Please post all follow-ups to the newsgroup only.

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:q0csktcrt6rbpnbrm...@4ax.com...

Joseph M. Newcomer

unread,

Jul 15, 2001, 4:11:58 PM7/15/01

to

Because you don't know what the superclass implementation actually
does. By circumventing it and calling EndDialog yourself you run the
risk that a change in the implementation will render your code
incorrect. Stick with the abstractions provided unless there is a
compelling reason to violate them. There is not in this case.
joe

On Thu, 12 Jul 2001 18:26:39 -0500, "Jeff Partch"
<airb...@airmail.net> wrote:

>Why not call EndDialog(-1) and return FALSE?
>
>Jeff...

Joseph M. Newcomer [MVP]

Jeff Partch

unread,

Jul 15, 2001, 5:10:15 PM7/15/01

to

Well I'll bite, Joe! I thought the calling EndDialog was a (possibly the) documented way to destroy
a dialogbox during WM_INITDIALOG failure..."A dialog box procedure can call EndDialog at any time,
even during the processing of the WM_INITDIALOG message. If your application calls the function
while WM_INITDIALOG is being processed, the dialog box is destroyed before it is shown and before
the input focus is set."...what would the superclass be doing that would invalidate this
requirement?

Jeff...
--
Please post all follow-ups to the newsgroup only.

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:m6u3lt8fvmcmq36co...@4ax.com...

Joseph M. Newcomer

unread,

Jul 18, 2001, 10:18:40 PM7/18/01

to

This is true. It can call EndDialog during WM_INITDIALOG. That is a
statement about the raw C API. When you start putting MFC wrappers
around things, you need to adhere to the expected behavior. In fact,
calling CDialog::OnCancel eventually calls EndDialog, thus meeting the
spec that it can be called during WM_INITDIALOG. But in MFC we could
have more going on here than just EndDialog (for example, I frequently
subclass dialogs; therefore, by calling OnCancel, it means my
superclass OnCancel is called, which may have to free up resources
that the superclass allocated and the subclass knows nothing about).
By adhering to the abstraction, I win; if I called EndDialog
explicitly, my superclass would not be called, and I could leak
resources.
joe

On Sun, 15 Jul 2001 16:10:15 -0500, "Jeff Partch"
<airb...@airmail.net> wrote:

>Well I'll bite, Joe! I thought the calling EndDialog was a (possibly the) documented way to destroy
>a dialogbox during WM_INITDIALOG failure..."A dialog box procedure can call EndDialog at any time,
>even during the processing of the WM_INITDIALOG message. If your application calls the function
>while WM_INITDIALOG is being processed, the dialog box is destroyed before it is shown and before
>the input focus is set."...what would the superclass be doing that would invalidate this
>requirement?
>
>Jeff...

Joseph M. Newcomer [MVP]

Jeff Partch

unread,

Jul 19, 2001, 5:30:49 AM7/19/01

to

But it's true for CDialog::EndDialog too..."You can call EndDialog at any time, even in
OnInitDialog", and although we are pretending not to know the behaviour of the superclass, it might
be good to note that when the MFC CDialog::OnInitDialog fails it too calls EndDialog. OnCancel seems
like a strange place to be freeing allocated resources in any event because there is no guarantee
that it will ever be called. Wouldn't OnDestroy or OnNcDestroy be better? Are you sure that you
aren't just defending a bad design habit?

Jeff...

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:qmgcltodtlhdbulv9...@4ax.com...

Joseph M. Newcomer

unread,

Jul 23, 2001, 12:48:20 AM7/23/01

to

Depends on the specified behavior. For example, on OnOK, I don't free
the resources, because they represent the successful completion of the
dialog, but on OnCancel, I do, because they will not be used because
the dialog is cancelled. On(Nc)Destroy is unconditional and cannot
distinguish the two cases unless you add some variable somewhere to
say whether or not the values should be released, hence, it makes
sense to do it in OnCancel.
joe

On Thu, 19 Jul 2001 04:30:49 -0500, "Jeff Partch"

Jeff Partch

unread,

Jul 23, 2001, 3:50:45 AM7/23/01

to

Well I give up, Joe. Each to his own. But I'd think that this behaviour and requirement of your
superclass should be documented. "Do not call EndDialog in OnInitDialog..." and "DoModal may
return -1 on failure and it may return IDCANCEL...".

Jeff...

"Joseph M. Newcomer" <newc...@flounder.com> wrote in message

news:42bnltcourcn8kacq...@4ax.com...

Raj Kulkarni

unread,

Jul 31, 2001, 5:55:18 PM7/31/01

to

The cases that are being talked about here seem to apply to destroying a
modal dialog box. What I need to know is how to destroy a modeless dialog
box from "OnInitDialog".

Raj

"Jeff Partch" <airb...@airmail.net> wrote in message
news:OI5Wdw0EBHA.1328@tkmsftngp07...

Jeff Partch

unread,

Jul 31, 2001, 7:10:34 PM7/31/01

to

Hi, Raj!

"Raj Kulkarni" <rajku...@gl.com> wrote in message news:eEb#$tgGBHA.1836@tkmsftngp03...

> The cases that are being talked about here seem to apply to destroying a
> modal dialog box. What I need to know is how to destroy a modeless dialog
> box from "OnInitDialog".
>
> Raj
>
>

Well, my answer is still EndDialog if we're talking about an MFC CDialog. The various overrides available in the modeless CDialog
creation all wind up in...

BOOL CWnd::CreateDlgIndirect(LPCDLGTEMPLATE lpDialogTemplate, CWnd* pParentWnd, HINSTANCE hInst)

...which specifically checks for the EndDialog call during WM_INITDIALOG processing...

...

// handle EndDialog calls during OnInitDialog
if (hWnd != NULL && !(m_nFlags & WF_CONTINUEMODAL))
{
::DestroyWindow(hWnd);
hWnd = NULL;
}

...

// help with error diagnosis (only if WM_INITDIALOG didn't EndDialog())
if (hWnd == NULL)
{
...
return FALSE;

...

Although, according to MSDN Article Q193099, "FIX: CDialog::Create() Returns Incorrect Value Calling EndDialog", there was a bug in
this code (that would cause these CDialog::CreateXXX variants to return a non-zero value) that was, "fixed in the Visual Studio 6.0
Service Pack 1".

HTH,