locked
.Net target framework affecting the display of "Not Responding" on the title bar RRS feed

  • Question

  • Hi forum members,
    Recently, a client found that after an upgrade, the application no longer shows the "[Not Responding]" at the title bar when it is, well... not responding.
    After some investigation, we found that this happens because we upgraded the .Net framework version of our application from 2.0 to 4.0.
    We verified that by creating a small WinForms application with only a form and a single button on it.
    In the button's Click event handler we added Thread.Sleep(10000).
    We then ran the application, clicked the button and while the thread was sleeping, clicked on a few places on the form and tried to move it around.
    After a few seconds, we saw the 'Not Responding' message on the form's title bar.
    However, when we changed the Target Framework of the application to 4.0, we no longer saw that.
    Also, when the "Not Responding" is displayed (.Net FW 2.0 or 3.5), you are able to minimize the form.
    So this is also not available anymore now that the target framework is 4.0.
    Our client now complains that they have no way of knowing that the application is doing something in the background and also, when it is 'stuck' they cannot even minimize the screen to work on something else in the meanwhile.

    Any ideas?

    Lior.
    Sunday, March 1, 2015 4:14 PM

Answers

  • That sounds like .Net 4.0 moved the windows message pump and you're now caught out. What that application is doing isn't and has never been a correct way of doing things in Windows for anything other than perhaps a console window.

    Windows is just trying to keep the user informed that the single application process isn't responding to it's main windows' message queue.  Here's a read on what's actually happening: http://blogs.msdn.com/b/wer/archive/2009/03/19/let-there-be-hangs-part-1-not-responding.aspx.

    Your applications behaviour will change too as Windows versions change.  I believe later versions will prompt the user "The app is not responding... Close or Wait for it" type messages if the user does too much with it's window. 

    Either way, it's only going to get worse if you don't follow what Fred suggests and move the workload to another thread.

    Perhaps a suggestion:

    Instead of calling "DoWork(); and have the UI hang, wrap it in a Task, like this:

    Task.Run( DoWork() );

    You'll have to ensure you don't try touching the UI, because that's also off limits in a background thread.


    Darin R.

    • Marked as answer by Fred Bao Tuesday, March 17, 2015 2:02 AM
    Thursday, March 5, 2015 7:57 PM

All replies

  • I don't know what may have changed in .Net 4.0 to cause the different behaviour you describe.

    Have you considered fixing the underlying problem by moving the long-running operation to another thread using BackgroundWorker and using a ProgressBar to show the user that something is happening?

    Sunday, March 1, 2015 4:40 PM
  • Well, our application contains thousands of forms (it's a win forms application) and it is all over the place.

    so changing each button's handler to move to another thread is not an option.

    I was hoping to find some configuration somewhere to 'tell' the application to work as if it were still using .net FW 2.0 in that matter.

    Lior.

    Sunday, March 1, 2015 4:53 PM
  • You have thousands of forms with buttons that cause the application to become unresponsive?

    Is it an option to target version 3.5 Framework instead of 4.0?

    Sunday, March 1, 2015 4:57 PM
  • Thanks for your reply.

    Not all buttons cause the application to become unresponsive but quite a few have DB calls that might in some condition take longer than the user might expect and when the user will try to click another button - it used to display the 'Not Responding' message - notifying the user that something is still happening and the application is not just 'stuck'.

    Re-targeting at 3.5 is not an option because we rely on a 3rd party that is built with 4.0.

    Lior.

    Monday, March 2, 2015 7:58 AM
  • Hello,

    As far as I know the 'Not Responding' is a windows state which is controlled by the system, it maybe that since from the CLR 4 version, the team has changed this behavior. My suggestion is that you could write an explicit UI implemented to show user that something is still happening and the application is not just 'stuck'.

    Regards.


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Thursday, March 5, 2015 9:00 AM
  • That sounds like .Net 4.0 moved the windows message pump and you're now caught out. What that application is doing isn't and has never been a correct way of doing things in Windows for anything other than perhaps a console window.

    Windows is just trying to keep the user informed that the single application process isn't responding to it's main windows' message queue.  Here's a read on what's actually happening: http://blogs.msdn.com/b/wer/archive/2009/03/19/let-there-be-hangs-part-1-not-responding.aspx.

    Your applications behaviour will change too as Windows versions change.  I believe later versions will prompt the user "The app is not responding... Close or Wait for it" type messages if the user does too much with it's window. 

    Either way, it's only going to get worse if you don't follow what Fred suggests and move the workload to another thread.

    Perhaps a suggestion:

    Instead of calling "DoWork(); and have the UI hang, wrap it in a Task, like this:

    Task.Run( DoWork() );

    You'll have to ensure you don't try touching the UI, because that's also off limits in a background thread.


    Darin R.

    • Marked as answer by Fred Bao Tuesday, March 17, 2015 2:02 AM
    Thursday, March 5, 2015 7:57 PM