You may find this discussion useful,
Re-SetTimer.aspx[
^], it concerns long running code and keeping the GUI responsive. Read the entire thread as it discusses several ups and downs to the approach.
If you are new to programming windows, it would be good to learn threads and how to use them to process things outside of the GUI events / messages.
But if you are just looking for a quick way to fix whatever this program is and move on (like if it's homework), a message pump will do the trick.
--------
Updated to include the link I forgot the first time
--------
Updated again.
OK, my gut told me to not bother with this question at all. The comments on my solution / suggestion just confirm what my gut thought in the first place.
Threads vs Message Pumps are a religious war. There is no winner. There are people who swear that Threads are the only way to go and that all other forms of keeping the GUI responsive are bad practice and punishable in the most harsh way. Thread devotees seem willing to force the most novice programmer into learning about threading, synchronization, cross thread communication, etc right out of the box. Threads are a complex concept for most beginners and they should have their sea legs firmly in place before learning threads. Threads require a discipline to use effectively and not get screwed up and that discipline is picked up over time, not in Comp Sci 1.
Now, before I get crucified for not liking threads, let me say that I was around when threading got invented, I was the architect for a set of products for an embedded chip based kernel that included threading. I was my company's representative on the Posix Threading Committee and worked on the reference implementation for Posix Threads. I know threading well.
Threading is very useful and worth learning but it is not the solution to every problem. Message Pumps can be useful for folks who do the obvious, start processing when the "do it" button is clicked in their GUI and all they want to do is keep the screen / log window up to date as process proceeds. It even works fine if all you want to do is process a "Cancel" button during processing. Yes, you can get yourself into trouble but I can demonstrate those same problems will exist if you used the "do it" button to fire off a thread to do the work.
Back in the 80's when I was doing all that kernel work, we used to laugh at some folk's attempts to create as many threads as they could, the old saying was "if threads are good for you, 4,000 threads must be wonderful". So yes, you can misuse threads and one way I noted was to use threads to do the work and then also fire off multiple Message Pumps in threads too. Microsoft / MFC already gives you a Message Pump in the default GUI thread so unless it is *exactly that thread* that you have made compute intensive, there is no reason to add more to the application. And so, Albert, I completely disagree with you. The Message Pump, if you are going to use one, CANNOT be in it's own thread but be used inside the long running code in the GUI thread because you have pre-empted the one provided by MFC.
OK, I'm going to stop with this, as I said, there is no winner in a religious war. Upvote this, downvote this, whatever, I'm no going to bother revisiting this ever again.
Submit an article or tip