B
Bob Chambers
Hi there,
Can anyone comment on two apparent problems I've noticed with the
"BackgroundWorker" class (e.g., the design pattern itself). The canonical
examples always show a demonstration of a "Cancel" button handler invoking
"BackgroundWorker.CancelAsync()" but two possible problems then arise:
1) What happens if the "Cancel" button handler is running around the same
time that the worker thread is exiting. In this case, the worker thread may
exit in which case the "RunWorkerCompleted()" handler will be invoked as
soon as the "Cancel" handler returns. The "RunWorkerCompletedEventArgs"
argument passed to "RunWorkerCompleted()" will then indicate that the thread
exited either normally or via an exception but not by cancellation even
though the "Cancel" handler just ran!
2) If any dialogs are displayed on the main UI thread while the background
thread is running (say, merely by asking the user to confirm cancellation
when they click the "Cancel" button), then because a dialog pumps messages,
if the background thread ends while a dialog is still on screen then
"RunWorkerCompleted()" will get called prematurely. IOW, using the example
just cited, the confirm "Cancel" dialog may still be on screen at this point
but "RunWorkerCompleted" is now called indicating the thread ended normally
or via an exception which won't be true if the user then confirms
cancellation (moreover, after confirming cancellation, the "Cancel" handler
will then try to cancel the background thread which has already finished and
"RunWorkerCompleted()" won't be called again).
Can anyone comment on these issues. Thanks.
Can anyone comment on two apparent problems I've noticed with the
"BackgroundWorker" class (e.g., the design pattern itself). The canonical
examples always show a demonstration of a "Cancel" button handler invoking
"BackgroundWorker.CancelAsync()" but two possible problems then arise:
1) What happens if the "Cancel" button handler is running around the same
time that the worker thread is exiting. In this case, the worker thread may
exit in which case the "RunWorkerCompleted()" handler will be invoked as
soon as the "Cancel" handler returns. The "RunWorkerCompletedEventArgs"
argument passed to "RunWorkerCompleted()" will then indicate that the thread
exited either normally or via an exception but not by cancellation even
though the "Cancel" handler just ran!
2) If any dialogs are displayed on the main UI thread while the background
thread is running (say, merely by asking the user to confirm cancellation
when they click the "Cancel" button), then because a dialog pumps messages,
if the background thread ends while a dialog is still on screen then
"RunWorkerCompleted()" will get called prematurely. IOW, using the example
just cited, the confirm "Cancel" dialog may still be on screen at this point
but "RunWorkerCompleted" is now called indicating the thread ended normally
or via an exception which won't be true if the user then confirms
cancellation (moreover, after confirming cancellation, the "Cancel" handler
will then try to cancel the background thread which has already finished and
"RunWorkerCompleted()" won't be called again).
Can anyone comment on these issues. Thanks.