I have problem in with PostQuitMessage, my app has several windows running at the same time sometimes, and when PostQuitMessage is called to destroy one window it will also destroy all other windows created after that window.

This behaivour is also noted in MSDN and it is because all windows are created from the same thread. Ofcourse I need to have every window destroy only it self without affecting others, but without using PostQuitMessage() window proc loop (GetMessage) will never exit.

Is there any other way to completely destroy and break its loop, without affecting other windows from the same thread?
Posted on 2004-04-07 07:11:22 by Mikky
I don't have a real clear picture of your program's window hierarchy, but maybe the DestroyWindow function might be what you're looking for.
Posted on 2004-04-07 07:21:47 by Mecurius
Hm, nope.. DestroyWindow destroys window but it doesnt ends up message loop, and thus loop is still active even after window is closed. You need to PostQuitMessage() in order to stop loop but then again, that will destroy all other windows from the thread.
Posted on 2004-04-07 07:54:31 by Mikky
What do you mean the loop is still active? If there is only one thread, there is only one loop.
Posted on 2004-04-07 11:52:44 by Mecurius
:confused:

I'm not really sure of what you want, but if the loop is in your app you can implement it in any way you wish. The WM_QUIT message really does nothing, just changes the return value from GetMessage. But yuo can implement the message loop in any way you want.

Anyway, if you still have active windows in your thread, why would you like to quit the message loop? What you are describing is just the normal, desired way WM_QUIT and WM_CLOSE work.
Posted on 2004-04-07 15:52:39 by QvasiModo

Hm, nope.. DestroyWindow destroys window but it doesnt ends up message loop, and thus loop is still active even after window is closed. You need to PostQuitMessage() in order to stop loop but then again, that will destroy all other windows from the thread.

You can call PostQuitMessage when your main window receives a WM_DESTROY message. If all the other windows descend from the main one, you will only get this message in your main windowproc once ALL of them were destroyed.

If they don't all descend from a single window, you can store their handles in an array. When a window is destroyed, remove it's handle from the array and call PostQuitMessage. When you get the WM_QUIT message, in your msg loop, you only quit when all of them have been destroyed.

Hope that helps. :)
Posted on 2004-04-07 15:55:55 by QvasiModo
Ok to put it simply
1. Create first window with CreateWindowEx
2. at WM_CREATE (or at some other msg) of the first window create second window with its own message loop etc..

Now if you call PostQuitMessage() for the first window, it will automatically destroy the second window, and I want to avoid this and to create each window independently.
Posted on 2004-04-07 16:49:52 by Mikky
I think I get it now :)


Ok to put it simply
1. Create first window with CreateWindowEx
2. at WM_CREATE (or at some other msg) of the first window create second window with its own message loop etc..

Now if you call PostQuitMessage() for the first window, it will automatically destroy the second window, and I want to avoid this and to create each window independently.

Well, it's threads that have message loops, not windows. All windows created by a single thread will be handled by the same loop, as GetMessage will not work with windows created by other threads. PostQuitMessage is used to break the current thread's message loop, it can't be used on per-window basis, and it doesn't destroy any windows.

What you can do is simply create a second thread to call CreateWindowEx and handle the new window. :)
Posted on 2004-04-07 17:05:04 by QvasiModo
Or just use a counter for the total number of windows created, and quit the thread when all are gone.
Posted on 2004-04-07 17:16:54 by Sephiroth3

Or just use a counter for the total number of windows created, and quit the thread when all are gone.

Right, much better than my array idea.
Posted on 2004-04-07 18:57:55 by QvasiModo


Right, much better than my array idea.


But with a thread for each window, depending on the nature of the program, the user interface will be more responsive as one window cannot block the other windows from processing messages.
Posted on 2004-04-07 20:30:08 by Mecurius
Blocking will occur if two or more windows send messages to each other with blocking APIs. It's a common error when someone first tries this multithread strategy.
Posted on 2004-04-07 22:04:14 by tenkey

Blocking will occur if two or more windows send messages to each other with blocking APIs. It's a common error when someone first tries this multithread strategy.


I was actually refering to the case where there is one thread for the message loop for Window1 and Window2. If Window1 has lengthy processing (such as a db connect or network I/O) Window2 will not respond to WM_PAINT or any other message. If Window1 and Window2 were created on two different threads, Window2 would continue to process messages and the application would be more "responsive".

What you say about the threads blocking each other is true. Unfortunatley, multithreading the UI in Windows is pretty tricky and full of gotchas.
Posted on 2004-04-07 22:50:29 by Mecurius
For lenghty operations it would be better to have a "worker" thread and a "GUI" thread. It's harder to make such mistakes with that strategy.
I still prefer Mercurius idea of a counter, it's simple and it works exactly like Mikky wants. :)
Posted on 2004-04-10 09:57:40 by QvasiModo