# Visual C++ & C++ Programming > Visual C++ Programming >  Prevent "Window not responding"

## ahmd

Hi everyone:


In my program I have to do some processing that may require up to 10-20 seconds to complete. Right before that I display a message box for the user that says, "Processing, please wait..." and the mouse goes into the hour-glass mode. This processing is done in the main thread so I guess as a side effect if someone drags another window over mine it doesn't redraw itself and looks like a white square. Moreover if that is done again my Windows XP shows that my program is not responding on the main title bar. All that goes back to normal when processing routine completes.

I searched this forum for solution and it seems like the most common one is to put all of my processing in a separate thread. I understand it, but that would require quite a lot of re-coding, which I'm trying to avoid. 

In light of that I was thinking, is there an API that I can maybe call once in awhile from my processing routine that will allow to update the main window and make this "Not responding" message go away?

----------


## RogerThat123

When does it say not responding? The whole 20 seconds?

----------


## hoxsiew

Is this an MFC app?  If so, and you have a processing loop of some sort, call theApp.PumpMessage(); from time to time during the loop.  If not MFC, you can still pump messages, but it's a bit more difficult.

----------


## JVene

Consider launching a thread to do the processing?

----------


## Skizmo

> This processing is done in the main thread


Bingo... The message should be "Main thread not responding"  :Wink: .

----------


## binyo66

Hide your main window until the initialization done  :Big Grin:

----------


## Syslock

Like the previous poster already mentioned, this is what worker threads are for.  Put your intensive processes in another thread, so it doesn't lock up your main app.

----------


## ahmd

> Like the previous poster already mentioned, this is what worker threads are for.  Put your intensive processes in another thread, so it doesn't lock up your main app.


Guys, I understand that, but as I said already, this will involve too much work (re-coding + added synchronization) that is not necessary in this case -- a user won't be able to do anything with the program anyway until this processing is done.

hoxsiew's idea about theApp.PumpMessage(); seems to be right on target, except it allows all messages to be processed (pretty much like if I was running it in a separate worker thread). Is there any way to let only drawing messages be processed?

----------


## Skizmo

Call this function now and then during the lengthy processing... 


```
void ProcessEvents ()
{
	MSG	stMsg;

	while (::PeekMessage (&stMsg, NULL, 0, 0, PM_REMOVE)) 
	{
		::TranslateMessage (&stMsg);
		::DispatchMessage (&stMsg);
	}
}
```

----------


## hoxsiew

> Guys, I understand that, but as I said already, this will involve too much work (re-coding + added synchronization) that is not necessary in this case -- a user won't be able to do anything with the program anyway until this processing is done.
> 
> hoxsiew's idea about theApp.PumpMessage(); seems to be right on target, except it allows all messages to be processed (pretty much like if I was running it in a separate worker thread). Is there any way to let only drawing messages be processed?


Your choices are limited.  PumpMessage (or Skizmo's function) will process messages periodically during a lengthy process; but it sounds to me like you need to block some UI operations until the action is done.  For this there is not much choice but to use a worker thread and, say, run a modal popup dialog (with a progress bar or something) to block the UI.

----------


## krmed

There is one other possibility...

along with using the PumpMessage (or Skizmo's function), when you first enter your function that's going to do a long process, call

```
EnableWindow(FALSE)
```

This disables the main window, but the message pump will continue to pump messages. Since the main window is disabled, no mouse clicks, etc will be recognized.

Don't forget to call

```
EnableWindow(TRUE)
```

just before that function exits.

Hope that helps.

----------


## Skizmo

> This disables the main window, but the message pump will continue to pump messages.


I don't want to start a off-topic discussion here, but AFAIK the message pump will still be blocked by the running, lengthy task whether the window is enabled or disabled.

----------


## krmed

The idea is to disable the window before starting the long process and enable after it is complete. The message pump goes in the long process.


```
void CMyView::OnStartProcess()
{
	EnableWindow(FALSE);
	DoLongProcess();
	EnableWindow(TRUE);
}

void CMyView::DoLongProcess()
{
	int i = 0;
	for (i = 0; i < 10000000; i++)
	{
		...    // some of your long process
		if ((i &#37; 1000) == 0)    // do this every 1000 times through the loop
		{
			ProcessEvents();
		}
		...    // more of your long process
	}
}

void CMyView::ProcessEvents ()
{
	MSG	stMsg;

	while (::PeekMessage (&stMsg, NULL, 0, 0, PM_REMOVE)) 
	{
		::TranslateMessage (&stMsg);
		::DispatchMessage (&stMsg);
	}
}
```

----------


## ahmd

Oops. Sorry, I missed all the replies. Thanks everyone!

I tried the EnableWindow() and theApp.PumpMessage(); approach and it worked like a charm. The only downside that I've encountered so far is that when the main window is in "disabled" mode, it disappears from the task bar and from the task switch (Alt+Tab), as well as it doesn't respond if I try to switch focus to it by clicking on it. But everything gets back to normal after a call to EnableWindow(TRUE).

----------


## Arjay

> The only downside that I've encountered so far is that when the main window is in "disabled" mode, it disappears from the task bar and from the task switch (Alt+Tab), as well as it doesn't respond if I try to switch focus to it by clicking on it. But everything gets back to normal after a call to EnableWindow(TRUE).


Yep.  That's why the proper way to do lengthy processing is in a separate thread.

Many developers don't like using a second thread because they think it's too complex. Imo, sometimes a program gets more complex trying to keep everthing working in a single thread than rather going to a secondary thread from the start.

----------


## ahmd

Arjay, I agree with you but believe me it would be much more complicated for us to put everything into a separate thread -- I'd definitely do it if I was to start from scratch.

I wish I could only put this main window into a modal loop for a duration of this processing. Is there any way to do that?

----------


## Arjay

Naw, it's not worth it.  Chalk this one up to experience.  Next time put the lengthy processing in another thread.  It takes a bit of time to ramp up to multi-threading, but once you do it, you'll actually find it's easier to do. 

With multi-threading you can control the start, pause, resume, and stop of the secondary operation - it actually turns out to be easier than trying to do all in the main thread.  Sshhh, it's kind of a secret.

----------


## ahmd

> Naw, it's not worth it.  Chalk this one up to experience.


What do you mean -- putting the main window into a modal loop? Can someone explain if it's possible to do that?

----------


## Arjay

> What do you mean -- putting the main window into a modal loop?


A basic UI design goal is for the UI to remain responsive to the user through any operations.  The simplest way to do this is put long running or cpu intensive operations into a separate thread.  That way, you can control the thread from the UI thread (start, pause, resume, stop, etc.) and the UI thread remains totally responsive.

Another basic design goal is to keep the presentation code (i.e. UI) separate from the 'work' part of the code.  This allows you to sway out the presentation layer without impacting the underlying work code and vice versa.

With a single threaded application, everything more or less becomes a hack trying to keep the UI thread responsive.  The separation that should be between the presentation and work layers goes out the window because now the work layer has to have knowledge of the UI.  If you want to have the level of control that the MT approach provides, a single threaded app can get rather complex and messy trying to implement the ability for the app to remain responsive, be able to control the operation, and so on.

Because of this, if you want to continue to go the single threaded route, I believe you can achieve acceptable results by peppering PumpMessage calls throughout your work code, but if you expect more, then IMO you'll need to move to multiple threads.

----------


## Brent720

I have this exact same problem with my C++/CLI program!

Thanks for all the replies.

I am not sure how to start a separate thread, so that is
still TBD.

Anyone got a simple example of how to do that?    :Smilie:

----------


## ahmd

> IMO you'll need to move to multiple threads.


Arjay, thanks, but it looks like I'm gonna stay with a single-threaded environment in this case. You see, the code that does all the processing is very complex, I didn't write it (a guy did it before me) and I don't even understand some parts of it (or I should better say, I didn't dedicate time to learn it.) My goal at the moment is to fix this situation when the main window becomes un-responsive. I think I already did that with the use of EnableWindow() on both ends of this lengthy processing and by calling theApp.PumpMessage() while processing, but, as I pointed out before, the only downside of this approach is that the main window disappears from the task bar during the time when EnableWindow(FALSE) was called.

I haven't tried it yet, but I got an idea. My fixation was to somehow put the main window into a modal loop and then it hit me. What if instead of displaying a user message in the main window (I mean something that says, "Processing, please wait...") I create a small dialog box without a title bar and no close button and display it before the processing begins using DoModal(). In this case it will put the main window into the modal loop. Then throughout processing I will still be calling theApp.PumpMessage() and at the end I will do SendMessage(WM_CLOSE) to this small dialog window to close it, that will also remove the main window from the modal loop.

What do you think, can this work?


PS. Brent720, follow all the previous posts, they have enough info for you to implement it in your project.

----------


## krmed

Another option (instead of just disabling the entire main window using EnableWindow) could be to individually disable (and the enable later) the individual controls that cannot be used during processing.

This would allow your app to still appear in the task bar, ALT-TAB would still switch to it, and you could move it around on the screen.

Of couse, as already pointed out, the best solution would have been a multi-threaded app.

----------


## Brent720

Thanks!  What a difference a day makes!  And a night's sleep!   :Smilie: 

Since postiing that, I have solved a problem with exception handling and now my program runs much faster, so it's no longer a problem in that exact situation, but there are other situations where the program could become nonresponsive.  My program now loads my dictionaries in a few seconds instead of many minutes.   :Smilie:   So the timeout/non-responsive situation never arises, but it's best to prevent it from being able to happen.

----------


## Emin56

> Call this function now and then during the lengthy processing... 
> 
> 
> ```
> void ProcessEvents ()
> {
> 	MSG	stMsg;
> 
> 	while (::PeekMessage (&stMsg, NULL, 0, 0, PM_REMOVE)) 
> ...


Thanks for the code. It worked for me in win 7 32 bit WinApi app.  :Wink:

----------

