locked
Winfoms Multithreading Issue - Moving from 1.1 - 2.0 RRS feed

  • Question

  • Please help me on the following , the issue details ...

    We were having a win forms application built in .Net 1.1, we have upgraded that application to 2.0 ., everything went fine all thanks to VS 2005 upgrade Wizad

    When we run the application using .Net 2.0 and VS 2005 we are getting the following error

    "Cross-thread operation not valid: Control 'statusBar' accessed from a thread other than the thread it was created on. "

    We know how to resolve this error, but for this we have test each and every part of the application as at compile time we can't know which code can generate this error...

    .Net 1.1 framework was somehow ignoring or supressing this error that why application was working fine with 1.1 and .Net 2.0 is not allowing this and thorwing InvalidOperationException

    Is there any way around we can supress/ignore this error in .Net 2.0 as well ?

    Regards
    Saurabh Sondhi

    Thursday, January 15, 2009 2:46 PM

Answers

  • Hi!


    No, you can't and you should not supress it. Consider using a Backgroundworker component to separate the UI from the threads and to create those threads. It would take some refactoring, but this is the best waz to do it.

    Regards,
    Lucian Baciu, http://studentclub.ro/lucians_weblog
    Thursday, January 15, 2009 9:13 PM
  • This test wasn't performed in .NET 1.x.  It got added because so many programmers got it wrong, causing random and undiagnosable application failure.  It can be suppressed but I'm not going to tell you how.  Fix the bug.  The exception won't be raised when no debugger is attached.

    Hans Passant.
    Friday, January 16, 2009 5:15 AM
  • Hi Saurabh Sondhi,

    Like others suggested, you'd better fix your application. When we try to access the control in a thread other than the thread creating that control, it always causes thread safe problems. You should marshal the call to the control's thread by using Invoke or BeginInvoke.

    If you just don't want to check this exception, there's such a static property called CheckForIllegalCrossThreadCalls Property, and you can set it to false to achieve the goal. Please turn to this passage for the detail.

    Best regards,
    Bruce Zhou

    Please mark the replies as answers if they help and unmark if they don't.
    Tuesday, January 20, 2009 7:18 AM

All replies

  • Hi!


    No, you can't and you should not supress it. Consider using a Backgroundworker component to separate the UI from the threads and to create those threads. It would take some refactoring, but this is the best waz to do it.

    Regards,
    Lucian Baciu, http://studentclub.ro/lucians_weblog
    Thursday, January 15, 2009 9:13 PM
  • This test wasn't performed in .NET 1.x.  It got added because so many programmers got it wrong, causing random and undiagnosable application failure.  It can be suppressed but I'm not going to tell you how.  Fix the bug.  The exception won't be raised when no debugger is attached.

    Hans Passant.
    Friday, January 16, 2009 5:15 AM
  • Hi Saurabh Sondhi,

    Like others suggested, you'd better fix your application. When we try to access the control in a thread other than the thread creating that control, it always causes thread safe problems. You should marshal the call to the control's thread by using Invoke or BeginInvoke.

    If you just don't want to check this exception, there's such a static property called CheckForIllegalCrossThreadCalls Property, and you can set it to false to achieve the goal. Please turn to this passage for the detail.

    Best regards,
    Bruce Zhou

    Please mark the replies as answers if they help and unmark if they don't.
    Tuesday, January 20, 2009 7:18 AM
  • Thanks Buddy for your help ..
    Tuesday, January 20, 2009 8:18 AM