getter function from my GUI class. That way I can check it to see when the
thread is done after I get the notification message. I set the bool right
after exiting the thread loop. The procedure works well for me. I make it
"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