How can I "DoEvents" in C++
Peter Grancourt
I have a function, which takes some time to execute, and I'd like to show a
progress bar.
While I can update the progress bar object, it must wait until it recieves
its WM_PAINT Message before it paints, and that does not happen until my
function returns.
Any Ideas? I'm sure I'm not the only one who has had this problem ;<)
Payson White
processing loop.
<outer loop>
{
..
MSG msg;
while (PeekMessage(&msg,0,0,0,PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
} // end of outer loop
-----------------** -- Posted from CodeGuru -- **-----------------
http://www.codeguru.com/ The website for Visual C++ programmers.
Dan Zakaib
Another, more robust solution invloves multi-threading. You basically
"spawn" the work in your function in a seperate thread, leaving the main
message processing thread to process WM_PAINT messages. This way, you
need not alter your function. Look at beginthreadex()
(or AfxBeginThread() if you're using MFC) for info on how to do this.
Dan
In article <37b2d...@209.66.99.126>,
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Bob Moore
>I have a function, which takes some time to execute.....
There are several approaches you can take to this, basically they are,
in order from worst -> best :
Use a Timer
Use the MFC OnIdle mechanism
PeekMessage loop (equivalent of DoEvents)
Worker Thread
There is an article on my web site describing each in detail, and
giving their merits (or lack thereof). The URL is in my sig below, the
article is Tip #39.
Bob Moore [MVP]
http://www.mooremvp.freeserve.co.uk
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Due to an unreasonable amount of queries, I no
longer answer unsolicited email questions. Sorry,
no exceptions, and yes, this DOES mean you.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik Funkenbusch
news:37b504ff...@msnews.microsoft.com...
> There are several approaches you can take to this, basically they are,
> in order from worst -> best :
>
> Use a Timer
> Use the MFC OnIdle mechanism
> PeekMessage loop (equivalent of DoEvents)
> Worker Thread
I don't particularly agree with this. I don't think threads are better than
PeekMessage loops unless the design of your application somehow benefits
from thread useage. It's my belief that threads are overused and complicate
programs that do not need them.
I think recommending threads as a better solution generically is bad advice.
Gregory Junker
Erik Funkenbusch wrote in message ...
But you don't propose a better solution....what would be a better way than
threading? Threading is not complicated, and thread usage should not be
downplayed, at least not without some explanation...
grge
Erik Funkenbusch
news:elRYD$Y5#GA.309@cppssbbsa03...
DId you even read what I wrote? I didn't say threads weren't a good
solution. I said they are not a *BETTER* solution to a PeekMessage loop
*UNLESS* the design benefits from being multi-threaded (For instance, you
want to make the program work better under multiprocessor systems or using
threads would simplify the code).
My problem was that you recomended threads as being better than a
PeekMessage loop without any kind of qualification.
If all you want to do is process messages during a long operation, a
PeekMessage loop is simple, straight forward, and doesn't overly complicate
the design of the application. That's not to say that threads don't have
their place. They do.
Gregory Junker
I didn't recommend anything as being better than anything else....check
agin, perhaps you should read closer.
Erik Funkenbusch
My appologies. I assumed you were the original poster. In any event, my
point still stands.
Bob Moore
>I don't particularly agree with this. I don't think threads are better than
>PeekMessage loops unless the design of your application somehow benefits
>from thread useage.
I used to think like that until I overstepped the use of peeking in
one multi-application system and got bitten hard by some nasty
re-entrancy problems (I firmly believed I was a master of the universe
at the time, an opinion which got kicked out of me in the back alley
of experience). I don't think that threads are "better" per se, simply
that they can turn out (in some circumstances) less problematic than
peeking.
>It's my belief that threads are overused and complicate
>programs that do not need them.
Now that I can at least partially agree with. Example : I'm working on
a system which sends a message to a piece of hardware and waits on the
result before proceeding. A colleague was all for using threads, but I
demurred and my design used peeking at the lowest level. Why ? because
the thread would simply send a message and wait for a response - the
problem was trivial and didn't warrant the use of threads. There's no
point using a thread if it doesn't actively do anything.
On the other hand, I've used both techniques extensively, know the
benefits and pitfalls of each, and can make an informed decision. I
contend that for someone with less experience, worker threads can
actually be less troublesome to implement. As always, YMMV.
Erik Funkenbusch
> On Thu, 12 Aug 1999 15:55:34 -0500, Erik Funkenbusch wrote:
>
> >I don't particularly agree with this. I don't think threads are better
than
> >PeekMessage loops unless the design of your application somehow benefits
> >from thread useage.
>
> I used to think like that until I overstepped the use of peeking in
> one multi-application system and got bitten hard by some nasty
> re-entrancy problems (I firmly believed I was a master of the universe
> at the time, an opinion which got kicked out of me in the back alley
> of experience). I don't think that threads are "better" per se, simply
> that they can turn out (in some circumstances) less problematic than
> peeking.
If you notice, I said "unless the design of the application somehow benefits
from thread useage". By that I meant that if you could simplify the design
by using threads, then i'm all for it. But if thread useage actually makes
the design more complex, then I'm not. I agree with you that experience can
be a harsh teacher (I've got plenty of scars across my knuckles from the
ruler of sister experience ;)
> >It's my belief that threads are overused and complicate
> >programs that do not need them.
>
> Now that I can at least partially agree with. Example : I'm working on
> a system which sends a message to a piece of hardware and waits on the
> result before proceeding. A colleague was all for using threads, but I
> demurred and my design used peeking at the lowest level. Why ? because
> the thread would simply send a message and wait for a response - the
> problem was trivial and didn't warrant the use of threads. There's no
> point using a thread if it doesn't actively do anything.
Yes, exactly. I think too many people jump on using threads because it's
the easy way out, when in reality it's the hard way. It just requires more
thought.
> On the other hand, I've used both techniques extensively, know the
> benefits and pitfalls of each, and can make an informed decision. I
> contend that for someone with less experience, worker threads can
> actually be less troublesome to implement. As always, YMMV.
The problem is that threads can be extremely dangerous in the hands of less
experienced developers. A good example is when you want to update windows
controls from a worker thread in an MFC app. Most novices don't understand
the thread local storage rules for window handles and get extremely confused
when the app starts asserting on them all over the place.