I am kind of confused about how DestroyWindow() works. According to the help files this function sends a WM_DESTROY message to the window it has just removed from the screen. In my WindowProc I have something like the following:

case WM_CLOSE:
{
      DestroyWindow(hwnd);
      return 0;
}

case WM_DESTROY:
{
      PostQuitMessage(0);
      return 0;
}

But when I close the window it gets removed from the screen alright, but I can still see it from my task manager. Should not DestroyWindow() send a WM_DESTROY message, which according to the code above would activate PostQuitMessage(0) (aka WM_QUIT) . So I was expecting my program to end completely.
Let me know if I am getting it wrong.

PostQuitMessage() only posts a WM_QUIT message to the message loop. The message loop may or may not receive the WM_QUIT message as soon as the PostQuitMesasge(0) is called.

Also as DestroyWindow does the destroying of the child windows, resources ...blah blah, there maybe a delay in that too. But I don't think it should take more than a couple of seconds. So the reason may depend on the delay you are experiencing. If it is only a small delay, then the reason must be what I explained. If not, then there must be resources still allocated to the calling thread.

Let me comment on the WM_CLOSE message also. I see that you are explicitly calling DestroyWindow at the WM_CLOSE message. This is unnecessary. If you just let the DefWindowProc handle it, it will automatically call the WM_DESTROY Message. So either you can remove the WM_CLOSE message handling part from the message loop ( if all that you do is call DestroyWindow() )

//case WM_CLOSE: Removed the WM_CLOSE handling 
//       
case WM_DESTROY:
{
      PostQuitMessage(0);
      return 0;
}
return DefWindowProc (hWnd, msg, wParam, lParam) ;

or

just insert a break like this.

case WM_CLOSE:
{
      // Do the user notification and whatever else you want to do
      //DestroyWindow(hwnd); // Commented out this function call
      break; // break to the DefWindowProc function
}

case WM_DESTROY:
{
      PostQuitMessage(0);
      return 0;
}
return DefWindowProc (hWnd, msg, wParam, lParam) ;

I need to do certain things when user tries to close the window. Say may be to ask him whether he actually wants to quit or not etc. That's why I cant let DefWindowProc() to handle it. But that was not the point. According to what I know the flow should be like this
WM_CLOSE > DestroyWindow() > WM_DESTROY > WM_QUIT(via PostQuitMessage).
After this I didn't expect to see the file in the task manager(consequently I cannot compile my program the second time bcos the file is still used by windows ).

As for the delay for PostQuitMessage() I always have to end the program through my task manager otherwise it stays there forever.

I need to do certain things when user tries to close the window. Say may be to ask him whether he actually wants to quit or not etc. That's why I cant let DefWindowProc() to handle it.

Okay. Then you have to handle the WM_CLOSE message. But even then you can do whatever you want to do in the message handler and let the message loop break to the DefWindowProc. ( like the second piece of code I posted )Anyway it is your choice. Whatever you do doesnot relate to this problem.

But that was not the point. According to what I know the flow should be like this
WM_CLOSE > DestroyWindow() > WM_DESTROY > WM_QUIT(via PostQuitMessage). After this I didn't expect to see the file in the task manager(consequently I cannot compile my program the second time bcos the file is still used by windows ). As for the delay for PostQuitMessage() I always have to end the program through my task manager otherwise it stays there forever.

That order is correct. And if you are using only the code shown in your first example, things are as you expect. But I think the problem is somehwere in the code that you have not posted. Maybe a hidden dialog box, or most probably a thread that was called by the main application is not properly uninitialized.

This article has been dead for over six months. Start a new discussion instead.