Windows XP - Not Responding
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
The only other approach is to implement a message loop within the long running function. This used to be general practice back in the 16 bit days and I think if you search here on codeproject, you'll likely find an article that describes how to implement what you are looking for. Chris Meech I am Canadian. [heard in a local bar] Gently arching his fishing rod back he moves the tip forward in a gentle arch releasing the line.... kersplunk [Doug Goulden] Nice sig! [Tim Deveaux on Matt Newman's sig with a quote from me]
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
Doug Knudson wrote: Short of a separate thread Why not create a separate thread to do the work? It would be the correct solution
"Opinions are neither right nor wrong. I cannot change your opinion. I can, however, change what influences your opinion." - David Crow
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
What you are describing is the textbook case for using a thread, your app must have some FUBAR'd design to preclude this. But another alternative that doesn't always occur to us Windows guys is to just do the long calculation in a whole seperate process, using any of the several available windows interprocess communications techniques to keep your GUI informed on how things are going.
-
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
Well, you've got your other options. But as David said, putting it in a separate thread is The Right Way. That's kinda what they're meant for, after all. FWIW, on Win2k and NT, Windows will also determine (at some point) that your app isn't responding. The difference under WinXP is that XP replaces your (unresponsive) window with a dummy window that displays the tile + "Not Responding", and allows the user to close it. They did this because, after six years of being told that the primary thread was for keeping the UI responsive and to do real work in other threads, we still weren't writing responsive apps.
"The time has come," the Walrus said, "To talk of many things..." -
Hi, I have a problem with a VC++ (6.0) dialog based application running under Windows XP. From a modal dialog, the user initiates some long-running activity, in a loop, that can take as much as 10 - 15 minutes to complete. If during the processing, the user covers the modal dialog with another window, even for a second or two, and then re-exposes it and clicks in the dialog, on Windows XP, "Not Responding" is displayed in the window title bar, causing the user to believe the app has died... but of course it hasn't. This behavior does not seem to occur under Windows 2000 or NT. There are a whole host of reasons why it would not be a good idea, in this particular situation, to start a new thread to do the processing, freeing up the dialog to respond to whatever messages XP is sending to determine if it is alive.... so.... Short of a separate thread... any ideas would be really, really appreaciated :) Thanks, Doug Doug Knudson
Hi all, Oh, how I miss the days of my youth when there was only one "correct" way to solve every problem... and I was always sure what the "correct" solution was to everyone's problems, even when I had no idea of the circumstances of the other person's problem. Oh well, those days are gone and I am much older now :-) At any rate, the winner is... Ravi Bhavnani for his excellent reference to the article on periodically pumping messages to keep the dialog alive. My sincere thanks to Ravi! Doug Doug Knudson
-
Well, you've got your other options. But as David said, putting it in a separate thread is The Right Way. That's kinda what they're meant for, after all. FWIW, on Win2k and NT, Windows will also determine (at some point) that your app isn't responding. The difference under WinXP is that XP replaces your (unresponsive) window with a dummy window that displays the tile + "Not Responding", and allows the user to close it. They did this because, after six years of being told that the primary thread was for keeping the UI responsive and to do real work in other threads, we still weren't writing responsive apps.
"The time has come," the Walrus said, "To talk of many things..."Only six years :wtf: I thought they have been rpeaching thread usage since Windows NT was released, back in something like 1993 :doh:
-
Only six years :wtf: I thought they have been rpeaching thread usage since Windows NT was released, back in something like 1993 :doh:
