Vista sets the "Application is not responding" state but the appis not crashing?

[MueMeister]

Hi guys,

I have an application which performs some tasks in a background
worker thread. If the app starts to export its data (which
takes up to 10 minutes) the GUI is getting pallid and the title
bar shows the ".. is not responding" state of my windows (which
is not true, since it is working correctly). In Windows XP
everything is fine.

1) Do I have to process certain messages in a new manner or maybe
I'm forced to process messages in Vista where in Windows XP has been
no need to do so?

2) I recognized that Vista performs this behavior really fast (lets say
after seconds). Is that a feature?

TIA
MueMeister

 

[David Hearn]

Hi guys,

I have an application which performs some tasks in a background
worker thread. If the app starts to export its data (which
takes up to 10 minutes) the GUI is getting pallid and the title
bar shows the ".. is not responding" state of my windows (which
is not true, since it is working correctly). In Windows XP
everything is fine.

1) Do I have to process certain messages in a new manner or maybe
I'm forced to process messages in Vista where in Windows XP has been
no need to do so?

2) I recognized that Vista performs this behavior really fast (lets say
after seconds). Is that a feature?

TIA
MueMeister

Vista will detect things which cause the GUI to not refresh properly -
basically it has enhanced the application hang detection. Not updating
the GUI is classed as a hang I believe.

I guess, the answer is to modify your code to ensure that the GUI is
able to paint itself during the data export.

D

 

[Steve Cochran]

This "not responding" has always been a problem. Sure its not responding,
its busy. That doesn't mean its not working.

Its too bad they made it worse.

You might try some multithreading if its an issue, but I'm not a big fan of
such myself.

steve

 

[Mike]

1) Do I have to process certain messages in a new manner or maybe
I'm forced to process messages in Vista where in Windows XP has been
no need to do so?

You just need to process events more often. If your data export is in a
loop, then put a DoEvents (or whatever call for your language) at the top of
the loop.

Mike

 

[MueMeister]

Thanks for Your answer Mike. It seems You experienced the
same issue?

I'll try it out.

MueMeister

 

[MueMeister]

David, Thanks for Your quick response

Vista will detect things which cause the GUI to not refresh properly -
basically it has enhanced the application hang detection. Not updating
the GUI is classed as a hang I believe.

I guess, the answer is to modify your code to ensure that the GUI is
able to paint itself during the data export.

D

 

[Richard Urban]

Right Steve,

Many programs that "are not responding" will continue (or terminate
correctly) if you just leave them be.

It would have been nice if Microsoft could have tried harder to develop an
applet that could tell the difference between "busy/working" and "not
responding".

--


Regards,

Richard Urban
Microsoft MVP Windows Shell/User
(For email, remove the obvious from my address)

Quote from George Ankner:
If you knew as much as you think you know,
You would realize that you don't know what you thought you knew!

 

[Steve Cochran]

DoEvents should be used as sparingly as possible, as it can really slow down
processes.

What I do when I have an iterative process is something like:

if i mod 1000 = 0 then
doevents
end if

But you do such at the peril of performance. I tell people to just leave
things alone and wait.

steve

 

[David Hearn]

Right Steve,

Many programs that "are not responding" will continue (or terminate
correctly) if you just leave them be.

It would have been nice if Microsoft could have tried harder to develop an
applet that could tell the difference between "busy/working" and "not
responding".

Surely if *the GUI* is not responding and isn't repainting itself, then
it's "not responding" and is appropriate to mark it as such. Correcting
the app so that doesn't happen is the (technically) best solution.

D

 

[Steve Cochran]

I think the problem lies in that the user interprets "not responding" as
"not working anymore". So they endtask it. Maybe it should just say "busy"
instead.

steve

 

[MICHAEL]

Surely if *the GUI* is not responding and isn't repainting itself, then it's "not responding"
and is appropriate to mark it as such. Correcting the app so that doesn't happen is the
(technically) best solution.

Well, then Microsoft needs to correct a few apps themselves. IE
and Windows Mail will through up that "not responding" crap many times.
Especially, Windows Mail, and has done so through all the beta
versions I have tested and still does it in the RTM version.
If you have a newsgroup that you've downloaded a lot of posts,
and then go to "Mark All as Read", 99% of the time that dumb
"not responding" will show itself in the top left. Even though it
can take forever at times to finish that simple little task, it is "busy"
and not "not responding".

As Steve said, many users will see "not responding" and figure
the program has frozen and will attempt to close it. Microsoft should
have figured out a better way to do this- it's just ignorant as it is now.


-Michael

 

[Steve Cochran]

With respect to WinMail:

This is not new. Its been happening with OE since OE5. They are just
trying to continue the tradition. <G>

They have improved performance some, but it could certainly be better. It
took a bit of a hit with the new file format, but much of that stuff is
database activity and they need to work on that.

steve