0

I have an app with quite a few windows each of a different CDialog-derived class.

My app's worked fine for years calling delete this from PostNcDestroy() but now that I'm looking around, I don't see any evidence that is correct or needed. What's the right way of getting rid of my CDialog-subclassed object?

Andrew Komiagin
  • 6,446
  • 1
  • 13
  • 23
Swiss Frank
  • 1,985
  • 15
  • 33
  • How do you create your windows? Show some code. – Jabberwocky Nov 27 '15 at 17:27
  • > How do you create your windows? Show some code. I have a framework with a Factory Method that opens windows given the class name in text. There's a common base class deriving from CDialog that in turn all my windows derive from. (It supports things like serializing the workspace, letting users customize how windows will be set up when initially opened, moving controls for window resizes, etc.) But ultimately, it simply calls new on the class. That base class calls Create() with the subclass's resource ID. I'm wondering if Create() before the subclass constructs is the problem. – Swiss Frank Nov 28 '15 at 01:42

1 Answers1

0

If the dialog is modeless, then calling delete this; in PostNcDestroy is the normal way of doing it.

See : https://support.microsoft.com/en-us/kb/103788

You need to be extra-careful not to access the dangling pointer after the dialog is dismiss.

for example, we do something like this:

void CMainFrame::DoSomething()
{ 
   MyModelessDialog* p = new MyModelessDialog;
   p->Create(IDD_MODELESS_DIALOG, ... );
}

/// ...
void MyModelessDialog::PostNcDestroy() 
{
    __super::PostNcDestroy(); // call base class to do clean up before deleting.
    delete this;
}
Andrew Komiagin
  • 6,446
  • 1
  • 13
  • 23
Max
  • 3,128
  • 1
  • 24
  • 24