Re: PostMessage and unprocessed messages
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> ha scritto nel messaggio
news:uLyYfgFgIHA.484@TK2MSFTNGP06.phx.gbl...
You can't discard the pending messages (deterministically) without syncing
up with the thread somehow. Even if you write a little flushing message
loop in IDCANCEL, the moment it decides there is nothing more to discard
the thread could post another message! So you must either (1) postpone
the dialog close until you _know_ the thread has exited, or (2) post the
messages to some other window (like the CMainframe) that you _know_ will
live longer than the thread.
I would discard option #2, and focus on option #1:
How would you suggest to implement the on-close handler?
I'm currently doing something like this:
<code>
// *** Dialog-box On-Close Handler ***
...
// m_workerThread is an instance of a custom thread class I wrote,
// which stores the thread handle, the thread ID, which has a
// destructor to safely delete the thread calling CloseHandle, etc.
if ( m_workerThread != NULL )
{
// Signal the thread to stop its working loop
m_workerThread->RequireCancel();
// Wait thread termination
::WaitForSingleObject( m_workerThread->GetHandle(), INFINITE );
// Thread cleanup
delete m_workerThread;
m_workerThread = NULL;
}
...
</code>
The RequireCancel() method sets a flag inside the thread class.
The thread procedure checks the value if this flag, and if this flag is
true, it breaks the loop, so the thread exits.
However, there could be some WMU_WORKER_PROGRESS messages pending (with an
LPARAM pointing to something that needs a delete!)... how could I get them
and do proper delete?
If I had a GC that would take care of deleting unused heap data, I would be
happy and I would not need to pay attention to these details.
(Note that Visual Studio is not signaling me memory leaks... I discovered
them using a custom tracing, tracing message data object construction and
destruction in ProgressMsgData class constructor and destructor
repsectively).
Thanks,
Giovanni