-
May 31st, 2011, 11:57 AM
#1
Wm_destroy
I've just been reading that WM_DESTROY is sent directly to a window's WndProc, bypassing its message queue. So if I had some code like this:-
Code:
MSG msg;
while (GetMessage (&msg, NULL, 0, 0)) {
if (WM_DESTROY == msg.message)
set_some_flag();
TranslateMessage( &msg );
DispatchMessageA (&msg);
}
The flag would never get set - because WM_DESTROY never appears in my message queue. In fact I've just tried that and it seems to be true.
So is there a way for me to know that WM_DESTROY has been (or is about to be) sent? For example is there any other message that Windows sends to notify the client that WM_DESTROY is about to be sent? This is a plain vanilla (Petzold style) app BTW - not using MFC.
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
May 31st, 2011, 11:59 AM
#2
Re: Wm_destroy
Why don't you want to handle WM_DESTROY directly in a window's WndProc?
Victor Nijegorodov
-
May 31st, 2011, 12:27 PM
#3
Re: Wm_destroy
Is the window modal? AFAIK, modal window has its own message loop.
-
May 31st, 2011, 12:37 PM
#4
Re: Wm_destroy
Alex - no it's not modal. There's one loop serving many external plugin windows. Victor - I suppose I could do but I'd need to use mutexes and stuff which I'd prefer not to do in my WndProc. At the moment I have a processing thread that looks broadly like this:-
Code:
void* VSTHost::process_thread (void *not_used)
{
FST* fst;
MSG msg;
bool plugin_deleted = false;
while (1) {
if (fst_first) { // A pointer to a global array of FST objects
pthread_mutex_lock (&plugin_mutex);
for (fst = fst_first; fst; fst = fst->next) {
if (fst) {
if (fst->hwnd) {
while (PeekMessage (&msg, (HWND)(fst->hwnd), 0, 0, PM_REMOVE)) {
if (/*** Detect WM_DESTROY somehow ***/)
plugin_deleted = true;
TranslateMessage( &msg );
DispatchMessageA (&msg);
}
}
pthread_mutex_lock (&fst->lock);
if (!plugin_deleted)
{
// Do some stuff
pthread_mutex_unlock (&fst->lock);
}
else
{
// Remove this FST from the FST list
plugin_deleted = false; // Reset for next time round
pthread_mutex_unlock (&fst->lock);
break;
}
}
}
pthread_mutex_unlock (&plugin_mutex);
}
g_usleep(20000);
}
}
As you can see, all the stuff I need is already in the processing thread so that would be a convenient place to do it but my WndProc will suffice if it can't be done here somehow.
"A problem well stated is a problem half solved.” - Charles F. Kettering
-
May 31st, 2011, 12:43 PM
#5
Re: Wm_destroy
PeekMessage Function
hWnd - a handle to the window whose messages are to be retrieved. The window must belong to the current thread. (The same for all Windows messages functions).
Is this true for your case?
-
May 31st, 2011, 12:48 PM
#6
Re: Wm_destroy
Yes, that bit all works fine except that I don't receive the WM_DESTROY messages (for reasons I now understand, having just read about it on MSDN). The other messages all get intercepted by my loop and successfully sent to the window.
"A problem well stated is a problem half solved.” - Charles F. Kettering
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|