Appearing as "Not Responding" more often in Windows 7

[D.Cook]

Windows 7 (as opposed to XP) has a different mechanism that decides how a window is not responding. When a window is deemed not responding, the words "Not Responding" are added to the titlebar, but most annoyingly, any further window paints (at least, DISPLAY or MESSAGE statements) are ignored until Windows deems it as responding after the process has finished (I assume from a WAIT-FOR statement).
The most information I've managed to find about this is here, which is not very much.
http://stackoverflow.com/questions/...e-not-responding-state-on-windows-7-wm-update

I have tried using PROCESS EVENTS every few seconds, which seems to help, but after a minute it seems to become not responding anyway. And if the window loses focus, it will be marked not responding within a few seconds.

Does anyone know of a way (within ABL) to tell Windows that it is actually responding? I have found reference to the OS function DisableProcessWindowsGhosting() which I hopefully could call, but I'm hoping to fix the root of the problem, which is that the AVM is not responding regularly to the messages sent by the OS.
Of course, getting right to the root of the problem would be to create a background worker thread which is not possible without an app server..

 

[D.Cook]

Actually the more I think about it, maybe this is an issue that should be fixed with the AVM. Because it happens not only in long loops, but when running a program that needs compiling (ie in dev environment). Also if a process takes a long time to open a new window (eg compiling or some app processing), the parent window is marked not responding, then when the new child window appears it appears behind the parent window. Quite annoying!

 

[Rob Fitzpatrick]

Actually the more I think about it, maybe this is an issue that should be fixed with the AVM. Because it happens not only in long loops, but when running a program that needs compiling (ie in dev environment).

What is happening is that Windows has determined that the process that owns the thread that owns the window is not responding to window messages (e.g. mouse and keyboard events). For as long as the process is in that state it will be marked as "Not Responding" in its title bar and in Task Manager, and if it receives a subsequent window message the DWM "frosts its glass" to indicate to the user that the UI is unresponsive.

You don't see this behaviour in multi-threaded apps because they have a dedicated UI thread that owns the window and remains responsive to window messages even when other threads are busy processing logic. The AVM is single-threaded and can't do this, as the UI thread is the logic thread. Window messages are only serviced outside of your business logic, unless it contains something like PROCESS EVENTS.

Also if a process takes a long time to open a new window (eg compiling or some app processing), the parent window is marked not responding, then when the new child window appears it appears behind the parent window. Quote annoying!

This is documented behaviour in the DWM in Windows 7. If it matters to you, you can use Windows API calls to find the window and give it focus.

 

[D.Cook]

unless it contains something like PROCESS EVENTS.

I have just tested with no restriction on PROCESS EVENTS (ie it is executed every time in the loop, many times a second), and when another window gains focus, this one is marked Not Responding after only a few seconds. But if the window keeps focus it will usually be ok. So it looks like even PROCESS EVENTS cannot completely help.

you can use Windows API calls to find the window and give it focus.

I have tried using SetForegroundWindow before, but still without success. I don't suppose you have any tips?

I think this issue is worth raising with Progress, so will do once I figure out how..

 

[Rob Fitzpatrick]

These KB articles may help; results from KB search for "SetForegroundWindow".

How to call the Win32 API function called SetForegroundWindow?
Incorrect z-order among application windows on Windows Vista or Windows 7
MS Word window called via COM activates in the background on Windows Server 2008

 

[D.Cook]

Thanks, I have ended up using the DisableProcessWindowsGhosting method, as it gives the desired behaviour. The window does not 'frost' and the display continues to update.
Have logged a case with Progress, but this result will do the job.

To define the procedure:

PROCEDURE DisableProcessWindowsGhosting EXTERNAL "USER32.DLL":
END PROCEDURE.

Then run it at any point in your program, it will last until the end of the session:

run DisableProcessWindowsGhosting.

 

[Cringer]

Thanks for posting your findings. I'm implementing the same fix here.

 

[Stefan]

Just played around with DisableProcessWindowsGhosting a bit. I am not too happy with the effect - the window is now completely unresponsive and cannot be closed or minimized. So be careful!

 

[Cringer]

Not on Win7 myself (upgrading tomorrow hopefully), but some colleagues who are haven't experienced this yet, Stefan. But thanks for the info.

D.Cook - would really appreciate it if you could report back the response from Progress when you get one.

 

[D.Cook]

Just played around with DisableProcessWindowsGhosting a bit. I am not too happy with the effect - the window is now completely unresponsive and cannot be closed or minimized. So be careful!

If you also use PROCESS EVENTS during the loop (eg every few seconds or every million records), the window will be movable and respond to other events. But it will only respond as often as PROCESS EVENTS is called.

Cringer - will do.

 

[RD_Man]

This Work Around COMPLETELY solved my immediate need. THANK YOU!

Thanks, I have ended up using the DisableProcessWindowsGhosting method, as it gives the desired behaviour. The window does not 'frost' and the display continues to update.
Have logged a case with Progress, but this result will do the job.

To define the procedure:

PROCEDURE DisableProcessWindowsGhosting EXTERNAL "USER32.DLL":
END PROCEDURE.

Then run it at any point in your program, it will last until the end of the session:

run DisableProcessWindowsGhosting.

 

[D.Cook]

Glad to have helped!

My Progress case has been closed with no further result, so I guess the best solution is the one I have described above.

Some relevant Knowledge Base articles:

• http://knowledgebase.progress.com/articles/Article/P186859

• http://knowledgebase.progress.com/articles/Article/P186860