"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:r3ckp3pllq8h391tdd3sg2pt2gcc4urap4@4ax.com...
That would work, but it's not a complete solution depending on the user
flow
you want. As I wrote earlier, in some cases, when Cancel is clicked, the
worker thread must be signaled to terminate, but that could take awhile
depending on how quickly the worker thread can check the BOOL. In that
case, you want the dialog to switch to something like, "Cancel in
progress,
please wait". And only when the worker thread is completely terminated do
you want the dialog to close.
****
Yes, that is how I do it. But I just use PostMessage to handle it,
because it is cleaner
than passing callback information around; I try to avoid callbacks, they
aren't really
natural mechanisms in C++, but an asynchronous PostMessage fits the
WIndows model rather
nicely. When I get the PostMessage, I take down the dialog.
joe
PostMessage() is good to communicate from worker thread --> UI thread
because it is asynchronous (good for 1 way traffic with no reply), and also
because it context switches to the UI thread so that the UI is free to
manipulate any windows/controls in response to the message.
But PostMessage() is not good to communicate from UI thread -> worker thread
due to the fact that the worker thread has no message pump. That's why
using a callback instead of a PostMessage() when the Progress dialog's
Cancel button is clicked is more flexible. It lets a worker thread handle
it as easily as a UI thread, so your Progress dialog is more resuable.
checking a bool directly. The callback will run in the context of the worker
thread, and to find out what to tell the thread function it has to do something
like check a bool anyway. Either way, the thread function has to stop what it is