Prevent Vista from marking my application as (non responding)

[R. Stegeman]

In our application we have long runs that can last several minutes or even
hours.
We are not using a separate thread for these runs, but instead, during the
run we periodically call a function to process at least some of the messages
that are on the message queue using PeekMessage calls with message filters
(yes, this is an old-win32-style approach, but making the application
multi-threaded is not really an option for us right now).

This approach worked fine on all previous window versions, but NOT on Vista!
Vista decides after some time that our application is not responding. In
fact Vista is right about that, but what I don't like is that as soon as the
application is marked as "not responding", it seems that WM_TIMER and
WM_PAINT messages are no longer send. And this means that in our application
no progress is shown anymore.

Does anyone have a solution for this problem?

If I use a PeekMessage without filtering, Vista will not mark the
application as "not responding", but then our application should start
checking very carefully which messages are allowed during this long run (for
example to prevent re-entrance of code).
Is there a specific message that Vista is sending to an application to
decide whether it is still responsive? I have tried all kind of message
tracing, but could not find the message that is triggering this.

[David Lowndes]

Post by R. Stegeman
Is there a specific message that Vista is sending to an application to
decide whether it is still responsive?

I've no idea what Vista does, but do you allow WM_NULL to be
processed?

Dave

[Ivo Beltchev]

Are you talking about processing the WM_NULL in the main window proc, or letting it through the PeekMessage filter?
According to MSDN, to check if the window is responding you send WM_NULL, not post it.

Post by David Lowndes

Post by R. Stegeman
Is there a specific message that Vista is sending to an application to
decide whether it is still responsive?

I've no idea what Vista does, but do you allow WM_NULL to be
processed?
Dave

[David Lowndes]

Post by Ivo Beltchev
Are you talking about processing the WM_NULL in the main window proc, or letting it through the PeekMessage filter?
According to MSDN, to check if the window is responding you send WM_NULL, not post it.

I'm just checking that you're not preventing the default processing of
it (in a timely manner).

Dave

[Paul Russell]

are you putting this on a second thread?

Rules/Behavior from MSDN:

If a top-level window stops responding to messages for more than several
seconds, the system considers the window to be not responding and replaces
it with a ghost window that has the same z-order, location, size, and visual
attributes. This allows the user to move it, resize it, or even close the
application. However, these are the only actions available because the
application is actually not responding. When an application is being
debugged, the system does not generate a ghost window.

I would also check the wRemoveMsg param rules relative to your specific
implementation.

Post by R. Stegeman
In our application we have long runs that can last several minutes or even
hours.
We are not using a separate thread for these runs, but instead, during the
run we periodically call a function to process at least some of the messages
that are on the message queue using PeekMessage calls with message filters
(yes, this is an old-win32-style approach, but making the application
multi-threaded is not really an option for us right now).
This approach worked fine on all previous window versions, but NOT on Vista!
Vista decides after some time that our application is not responding. In
fact Vista is right about that, but what I don't like is that as soon as the
application is marked as "not responding", it seems that WM_TIMER and
WM_PAINT messages are no longer send. And this means that in our application
no progress is shown anymore.
Does anyone have a solution for this problem?
If I use a PeekMessage without filtering, Vista will not mark the
application as "not responding", but then our application should start
checking very carefully which messages are allowed during this long run (for
example to prevent re-entrance of code).
Is there a specific message that Vista is sending to an application to
decide whether it is still responsive? I have tried all kind of message
tracing, but could not find the message that is triggering this.

[Pascal Dallongeville]

You can force Windows to disable Window ghost behaviour for your process by calling "DisableProcessWindowsGhosting" API.

http://msdn.microsoft.com/en-us/library/ms648415%28v=vs.85%29.aspx

Post by R. Stegeman
In our application we have long runs that can last several minutes or even
hours.
We are not using a separate thread for these runs, but instead, during the
run we periodically call a function to process at least some of the messages
that are on the message queue using PeekMessage calls with message filters
(yes, this is an old-win32-style approach, but making the application
multi-threaded is not really an option for us right now).
This approach worked fine on all previous window versions, but NOT on Vista!
Vista decides after some time that our application is not responding. In
fact Vista is right about that, but what I don't like is that as soon as the
application is marked as "not responding", it seems that WM_TIMER and
WM_PAINT messages are no longer send. And this means that in our application
no progress is shown anymore.
Does anyone have a solution for this problem?
If I use a PeekMessage without filtering, Vista will not mark the
application as "not responding", but then our application should start
checking very carefully which messages are allowed during this long run (for
example to prevent re-entrance of code).
Is there a specific message that Vista is sending to an application to
decide whether it is still responsive? I have tried all kind of message
tracing, but could not find the message that is triggering this.

I have no idea what Vista does, but do you allow WM_NULL to be
processed?
Dave

Post by Paul Russell
are you putting this on a second thread?
If a top-level window stops responding to messages for more than several
seconds, the system considers the window to be not responding and replaces
it with a ghost window that has the same z-order, location, size, and visual
attributes. This allows the user to move it, resize it, or even close the
application. However, these are the only actions available because the
application is actually not responding. When an application is being
debugged, the system does not generate a ghost window.
I would also check the wRemoveMsg param rules relative to your specific
implementation.

Are you talking about processing the WM_NULL in the main window proc, or =
letting it through the PeekMessage filter?
According to MSDN, to check if the window is responding you send =
WM_NULL, not post it.
to=20

I am just checking that you are not preventing the default processing of
it (in a timely manner).
Dave