Re: MFC wait dialog

From:

David Wilkinson <no-reply@effisols.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Sun, 11 Feb 2007 10:54:01 -0500

Message-ID:

<uk2DUTfTHHA.3592@TK2MSFTNGP03.phx.gbl>

Dan24 wrote:

On Feb 11, 2:24 pm, David Wilkinson <no-re...@effisols.com> wrote:

Dan24 wrote:

Hi,

I'm trying to create what seems to be a fairly simple thing to do - a
wait dialog in MFC.
To be more specific, I have a dialog which searches for files on the
hard drive and adds them to a listbox. Since searching is not done in
a worker / background thread, the main dialog (with the listbox) is
obviously not responding until the search is completed. Now all I want
to do is display a "Please wait" modal dialog while all this is
happening. I am aware of the fact I could use a worker thread for the
search, but I have no reason to allow interaction with the dialog
until the search is over. The best sollution I've come up with is
this:
1. Create a new thread
2. Call DialogBox() to display the wait dialog.
3. Change the cursor to busy (hourglass)
4. Post a WM_QUIT message to the thread when the search is done.

Is this the best solution or does MFC provide an easier way to achieve
this...?

Dan:

Not quite sure what you are saying here, but it sounds as if you are
doing it backwards. Never show any GUI in the secondary thread -- just
do the work there. And why WM_QUIT? The way I always use a worker thread
that is performing a finite task is to have it post a custom mesage back
to the main thread immediately before the worker thread function
returns. The handler waits on the thread handle (which should signal
immediately) so that it knows the thread has really ended, and then
continues with the program.

David Wilkinson- Hide quoted text -

- Show quoted text -

David,

As I already mentioned - in this scenario doing things in a worker
thread is pointless. I do not need to enable interaction with the UI
while the search is in process therefore there is no reason to do the
search in a seperate thread (and then send the data between threads to
update the listbox).

Dan:

Still not sure what you are doing here, because you say

1. Create a new thread

and then "in this scenario doing things in a worker thread is pointless."

Anyway, just because you do not need to interact with the wait dialog
does not mean that the main thread can be inactive. If the user covers
your wait dialog with another window, then your dialog will not be
repainted, which will confuse the user.

Why not just do it the way everybody else does -- GUI in the main
thread, work in the worker thread?

David Wilkinson