Board index » Visual Studio » MFC wait dialog

Visual Studio20
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...?


-

On Feb 11, 1:08 pm, "Dan24" <dlibe...@gmail.com>wrote:

One more question - when I call DialogBox() specifying the parent

window's hwnd, it is not responding. I assume this is because

DialogBox() sends a message to the parent window and if it is not

responding the function does not create the dialogbox until the

message is processed...



-

When in doubt, PumpMessages occasionally, look at the "something

happened" variable.

Dan24 wrote:



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

-

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

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).



-

Dan24 wrote:

Right, "Wait Dialog", don't need to interact with the UI.

-

On Feb 11, 1:08 pm, "Dan24" <dlibe...@gmail.com>wrote:

Solution, anyone? Again - what I'd like to do is display a wait dialog

while the main dialog is doing some processing and filling the list

control.

I don't want to use the worker thread solution and copy data between

threads - there is no need for user interaction while the list is

being filled, the user should be blocked and wait until the listbox is

filled. Creating another UI thread to display the wait dialog seems to

be the ideal solution, but is it?



-

Dan24 wrote:



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

-

"Dan24" <dliberty@gmail.com>wrote in message

But your UI needs to be free to respond to repaint messages, etc. during

your time consuming task. For example, if you do the time consuming task on

the main thread, and while that is going on, you maximize another app's

window to cover yours, then you restore that app's window so that yours is

once again visible, well... your window won't repaint because it won't

process the WM_PAINT message until after your time consuming task is done.

In fact, if it waits too long, Windows will put (Not responding) in your

caption.



This is why David W. said you must do your time consuming task on another

thread. Even if the user isn't supposed to interact with your window during

this time, the window must still be alive to respond to system-related

events. And if this is the case, it's easiest to just show your progress

window in the main thread and use a worker thread to perform the time

consuming task.



BTW, I would use a modeless dialog for your progress window.



-- David (MVP)





-

You are missing the point. If you feel a need to have interaction, you should/must use a

worker thread. If you don't use a worker thread, you won't have any interaction. So

instead of doing the right thing and creating a worker thread, instead you propose to

create a separate GUI thread, put the dialog in THAT (thus entering a seriously-high-risk

area of design). If you need to create a thread, you are better off creating a worker

thread to do the actual work and just pop up your dialog in your main thread.



Interaction means interaction. This means output to, as well as input from, the user. You

are suggesting a complicated, high-risk solution to a simple problem. Why not implement

the simple solution?

joe



On 11 Feb 2007 03:08:51 -0800, "Dan24" <dliberty@gmail.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

See below...

On 11 Feb 2007 03:34:03 -0800, "Dan24" <dliberty@gmail.com>wrote:



Note my earlier comment about going to "high-risk" solutions. You just did one, and got

done in by it. Wrong approach. Move the work to a worker thread and keep the UI in the

main GUI thread.



Hint: highly experienced MFC programmers would not choose your solution. The more

experience we have, the less likely we are to choose your solution.

joe



Joseph M. Newcomer [MVP]

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

See below...

On 11 Feb 2007 05:04:29 -0800, "Dan24" <dliberty@gmail.com>wrote:



You are making no sense. You say it is "pointless" because there is no interaction, and

the first thing you do is try to create something that has user interaction, and then

complain when the interaction doesn't work. Either you want an active GUI (if even to

display a "waiting" dialog) or you don't. If you do, that says "worker thread". If you

don't, then don't do anything that requires interaction, such as displaying a dialog

saying there is some active computation. You can't have it both ways; you are saying you

don't want a thread, and then you create a thread! Why? So you can have an interaction

with your user? Exactly what part of "I really want an interaction with my users" did I

fail to understand here?

joe



Joseph M. Newcomer [MVP]

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

Well, some of the serious experts here have told you how to do it: you do the work in a

worker thread and put up the dialog in your main thread. This is exactly how the

experienced MFC programmers do it, and that is what you asked advice about. We would

never consider your solution...in fact, we would consider it precisely the WRONG solution.

So what part of "the right way to do this is do your computation in a worker thread and

put the dialog in your main UI thread" are you failing to grasp?

joe



On 11 Feb 2007 06:39:27 -0800, "Dan24" <dliberty@gmail.com>wrote:



email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

On Feb 11, 9:09 pm, Joseph M. Newcomer <newco...@flounder.com>wrote:

If you call a dialog that says "Please wait" and repaints itself

interaction, than yes - I want interaction.

But I still think it's overkill to have a worker thread and transfer

data between threads when in fact there will be no user interaction

(responding to keyboard / mouse events) until the worker thread is

done anyway.



Even if you are correct, I don't like your attitude - this is a

newsgroup, not your private cigar club. People are free to conduct

discussions and ask questions without being insulted. I've been using

MFC for over 6 years and yes, I've always used worker threads since

they were indeed the best solution (and it just might be in this case

as well). As I mentioned in my first post in this thread, I am aware

of the worker thread solution. Worker threads are useful in the

scenario when you need the UI to continue to be responsive to user

commands such as canelling the operation or allowing the user to

continue working with the application. I've clearly mentioned that

this is a different scenario and thus the worker thread seemed to be

an overkill at first thought.



Thanks for your "help".



-

Dan24 wrote:

The fact that there will be no user interaction is not relevant! If you

lock up the application with a lengthy loop then it will fail to repaint

on demand, and if the user attempts to close it the "fails to respond"

message will appear. From the user's perspective, what you propose can

break the application.



In this case, where user input should be locked out during the lengthy

process, the issue of "transfer data between threads" is also not

relevant! The worker thread can access and modify the data freely if

the GUI thread is not accessing it.



--

Scott McPhillips [VC++ MVP]



-

It sounds like you don't get it.

Several guys that know what they are talking about explained to you

that this is not possible, and also explained why.

Asking again is not going to change the answer.



A dialog means a message pump. Interaction is not only the user pressing

a button.



If you really think a worker thread is overkill, then you have to eliminate

the dialog idea.



Idea: add another control saying "Working..." to your dialog and put it on

top of all the other controls, and make it hiden.

Then you start processing, show it and disable the other controls.

When done, enable the controls and hide the covering one.



With a bit of work you can make it look almost like a dialog.





--

Mihai Nita [Microsoft MVP, Windows - SDK]

www.mihai-nita.net">www.mihai-nita.net

------------------------------------------

Replace _year_ with _ to get the real email

-

To make sure: what Scott McPhillips explained about "fails to respond" will

still apply.

If you do the work in the main thread you block the message pump.

And if you do that, the application will look dead to the OS.





--

Mihai Nita [Microsoft MVP, Windows - SDK]

www.mihai-nita.net">www.mihai-nita.net

------------------------------------------

Replace _year_ with _ to get the real email

-

See below...

On 11 Feb 2007 11:42:46 -0800, "Dan24" <dliberty@gmail.com>wrote:



Yes. This is interaction

*****

And it is not overkill to have a UI thread that puts you at all kinds of risks? What part

of "threads that contain GUI elements are dangerous"...something everyone has told you,

repeatedly, in this thread, are you missing?



I repeat: you are solving the problem in the wrong way. Do the work in the worker thread.

Use the GUI thread for interaction.

*****

But when someone persists in saying "I want the experts to answer my problem" and then,

when all the experts tell you "don't do that" you insist that we are all wrong and you

want to do the opposite of what we are telling you, we being to think you are being overly

dense.

****

And everyone has pointed out that you are missing the key ideas about GUI objects in

secondary threads. Repeatedly, we are telling you that this is the wrong approach. We

are telling you that none of us would *consider* a solution like yours, and that the thing

to do is to reorient your solution. You keep getting hung up on differences between "GUI

objects" and "interaction" as if there is a distinction...apparently you think that if the

user is not providing input, there is not an "interaction", and we are telling you the

opposite, and you keep saying "but my problem is different" and we keep saying "no it

isn't, do the work in a worker thread". So how many times do how many of us have to tell

you that your solution doesn't make sense, before we start figuring out that you are not

paying attention?

****

You asked a question. Many people gave you the answer. The fact that you don't like the

answer doesn't change the fact that your solution is one that is complex and risky, and in

fact you've already said it doesn't work. And your solution is one that we would not

consider for an instant. We keep telling you this. And you keep not getting it. At some

point, my patience runs out. As long as you keep insisting that an interaction is not an

interaction, that it makes sense to place user-visible GUI objects in the secondary thread

that have parents in the primary thread, and other solutions that don't make sense, people

are going to continue to tell you that your solution is wrong.

joe

*****

Joseph M. Newcomer [MVP]

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-

On Feb 12, 5:43 am, Joseph M. Newcomer <newco...@flounder.com>wrote:

Just to make things clear, and this is really already out of the scope

-

I did not "insist" I had some kind of better solution, if I did I

wouldn't be posting in this newsgroup. I presented my problem and

wanted to get several opinions. The fact that I didn't accept the

first opinion I received is only natural and is one of the reasons

it's called a discussion.

I would like to remind you that it is possible to achieve what I

wanted without using worker threads. In VB for example, I would do the

background work while calling DoEvents() once in a while to process

windows messages and repaint the window thus using only a single

thread. Yes, this might not be a very clean solution but in this

scenario it just might suffice.

And to wrap things up, here's an example of a wait dialog implemented

in a seperate thread:

www.codeguru.com/cpp/controls/controls/article.php/c2269/">www.codeguru.com/cpp/controls/controls/article.php/c2269/



And yes, I agree, after reconsidering the facts, the worker thread

seems to be the best solution.



-

On 12 Feb 2007 01:58:10 -0800, "Dan24" <dliberty@gmail.com>wrote:



The example is rather poor. For example, it does polling, it polls the thread handle but

does not set m_bAutoDelete so the handle will become illegal if the thread terminates, it

still blocks the main GUI thread (with all the previously-reported problems); the idea

that an Event is used for polling (instead of a simple BOOL) is more than a little

strange; it represents a rather poor structure overall, and looks like a quick-and-dirty

hack by someone who didn't understand the message pump, threading, interthread

notification, events, etc. and cobbled something together that gives the illusion of

working under rather limited conditions. For example, start it running (I tried it),

cover up the main app, and uncover it. The waiting dialog is hidden, and the main app

doesn't repaint. For that matter, I hit a situation where only the animation control is

visible; the dialog around it doesn't repaint, for at least 5 minutes (while I was doing

something else). So while it is certainly published, it is not a particularly good

example of a solution to the problem. It embodies all the problems we already pointed

out, as well as being a bad example of interthread notifications.

joe

****

email: newcomer@flounder.com

Web: www.flounder.com">www.flounder.com

MVP Tips: www.flounder.com/mvp_tips.htm">www.flounder.com/mvp_tips.htm

-