tags:

views:

106

answers:

4

I'v created a window after creating my main one but calling DestroyWindow on its handle closes the entire application, how can I simply get rid of it?

it looks like this:

BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   HWND hWnd;
   HWND fakehandle;


   hInst = hInstance; // Store instance handle in our global variable

   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW | WS_EX_LAYERED,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

   fakehandle = CreateWindow(szWindowClass, "FAKE WINDOW", WS_OVERLAPPEDWINDOW,
       CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

   if (!hWnd || !fakehandle)
   {
      return FALSE;
   }
//some code
   DestroyWindow(fakehandle);


   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

how can I destroy this window without destroying my main one? I'm creating a dummy window to check for multisampling in OpenGL.

Thanks

+1  A: 

I suspect that specifying a parent (Fourth param from the end) for the "fakehandle" window instead of NULL, may help.

Also, you might check whether or not this quote "If the window being destroyed is a child window that does not have the WS_EX_NOPARENTNOTIFY style, a WM_PARENTNOTIFY message is sent to the parent." (From: msdn.microsoft.com) applies to your case.

Aaron H.
+3  A: 

I've just found this comment:

If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.

on the DestroyWindow MSDN page.

Could this have some bearing on your problem? Could you be setting the parent of hWnd where you've got //some code?

ChrisF
+1  A: 

Does the class referred to by szWindowClass call PostQuitMessage on receipt of WM_CLOSE or WM_DESTROY? That would stop your message loop first time round, I should think. (But if you're using the debugger, presumably you'd have spotted this?)

In any event, for your dumb window, for best results you'd need a second window class with a dumb WndProc. (I think DefWindowProc would be suitable.)

brone
+1  A: 

DestroyWindow() sends a WM_DESTROY to the window in question. If the WndProc passes WM_DESTROY on to DefWindowProc(), then DefWindowProc() will kill your app.

So, in your WndProc, create a handler for WM_DESTROY (if you don't already have one), and check the window handle. You should be able to differentiate between the two and take action from there.

// assuming you have the two window handles as hwnd1 and hwnd2
case WM_DESTROY:
    if( hwnd == hwnd1 ) {
        // this will kill the app
        PostQuitMessage(0);
    } else if( hwnd == hwnd2 ) {
        // chucking WM_DESTROY on the floor
        // means this window will just close,
        // and the other one will stay up.
        return;
    }
    break;

Be aware that if you do PostQuitMessage() on behalf of either window, it will take down your application, because PostQuitMessage() will terminate the message loop.

JustJeff