Cross-thread operation not valid

Cross-thread operation not valid

• Handerson

  There's no such message on NETCF (there’s a similar one) so either you using 3^rd party control or you’ve posted to the wrong forum.

  Anyway, it means you have to use Control.Invoke to access UI controls from worker thread.  That was discussed countless times, so search would reveal an answer it you don't know what Control.Invoke is or how to use it.

  MSDN article on Control.Invoke also has necessary information.

  
  
  

• Madhuchhanda

  Hi
  I am seeing an InvalidOperationException in InvokeRequired call even when it is being done safely. The following shows the stack trace.
  
  System.InvalidOperationException: Cross-thread operation not valid: Control 'MetricsControl' accessed from a thread other than the thread it was created on.
  at System.Windows.Forms.Control.get_Handle()
  at System.Windows.Forms.Control.get_InvokeRequired()
  .....
  
  Does anybody know why this would happen if you are using InvokeRequired.
  
  Thanks
  Rama.
  
  
  
  

• VSB

  take a look at this:

  http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=630558&SiteID=1

  my response to it is the code for safely invoking the UI to do some UI related stuff from a thread which the UI component was not created from.

  
  
  

• Marzullo

  This issue is much more complex than those who just say test "invoke required" and then use "control.invoke()'. There is, as far as I can find, nothing in these forums that treats the subject comprehensively.

  As Kartit just pointed out, if you're not in the control's thread, finding out whether 'invoke required' is set is a long drawn-out process (as far as I can figure out), where you have to find the form, get it's members, fine the control you're interested, and then access it's "invoke required" property to see whether its 'true' or 'false'. Not an easy task for the most experienced programmer, much less a novice. Very heavy use of 'reflection' to do this.

  At any rate, there is NO good discussion, nor any sample code that I can find, that address the intersection of several different issues which have an impact on how difficult it is to find a solution:

  1) Windows.forms 'binding' does not update a control's value from another field; it is unidirectional, from form to field, so to speak.

  2) VS 2005 does not generate good code for databinding; one must do it by hand, and even then, if one does what VS does, it's in the wrong direction, form to field, not field to form.

  3) Separately compiling the class(es) for the other thread(s), makes it extremely difficult to access things such as the control's properties ( the "Text" field, the "Invoke Required" property, etc). In order to use an "invoke" one has to have a delegate or use control.invoke(); unfortunately, the compiler cannot create a delegate based on a name it cannot check at "compile time", e.g., you can't use a variable and create the delegate at run time (as far as I have found out). Yes, it is difficult to gain addressability to the delegate if it's in the 'forms' class, since the forms class, many times is the 'main()' class and starts the other threads, but not always. Good code dictates that you really don't want any cross-thread meddling if you can avoid it. Trying to acquire a delegate from the UI class/thread for your use in another class/thread is very dangerous. Again, one has to resort to all sorts of reflection tricks to try to get the field.

  4) This is made more confusing in that .NET mangles the names for things, such as events associated with forms 'field' changes, but adding the word 'changed' to the name. If you don't know this, and it's not well documented, you can miss the boat forever trying to get an eventhandler hooked in to deal with the notification of the value changed.

  5) .NET will consistently give you "invalid operation" and "illegal cross thread call" exceptions EVEN IF you handle the problem in the set accessor for the forms textfield/whatever. This has to be solved by changing the property named "CheckForIllegalCrossThreadCalls" to 'false' instead of the default 'true'. Obviously, this should never be done unless you have code in the set accessor to deal with Xthread calls, but if you do, you still have to find this property and change it to false. This is very poorly documented also.

  I'm sure that many people have sorted out this problem in real-world applications. I would think, for instance, that many progress bars are the result of cross-thread updating, but I'm not privy as to how they've solved the problems.

  I took the time to respond because I have pursued this diligently over the last couple of weeks, and I have yet to find anyone that has addressed the whole set of issues in a concrete, concise manner, and providing sample code THAT WORKS.

  'nuff said

  Tom

  
  

• J A Y

  Kartit wrote:

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

  You can only access control properties on the same thread that created the control (usually the main thread).

  If you want to modify a property of a control on a second thread you must test Control.InvokeRequired in order to decide whether to call Control.[Begin]Invoke. This may require creating a custom delegate in order to give to Invoke.

  
  
  

• chaza

  TomL wrote:

  This issue is much more complex than those who just say test "invoke required" and then use "control.invoke()'. There is, as far as I can find, nothing in these forums that treats the subject comprehensively. As Kartit just pointed out, if you're not in the control's thread, finding out whether 'invoke required' is set is a long drawn-out process (as far as I can figure out), where you have to find the form, get it's members, fine the control you're interested, and then access it's "invoke required" property to see whether its 'true' or 'false'. Not an easy task for the most experienced programmer, much less a novice. Very heavy use of 'reflection' to do this. At any rate, there is NO good discussion, nor any sample code that I can find, that address the intersection of several different issues which have an impact on how difficult it is to find a solution: 1) Windows.forms 'binding' does not update a control's value from another field; it is unidirectional, from form to field, so to speak. 2) VS 2005 does not generate good code for databinding; one must do it by hand, and even then, if one does what VS does, it's in the wrong direction, form to field, not field to form. 3) Separately compiling the class(es) for the other thread(s), makes it extremely difficult to access things such as the control's properties ( the "Text" field, the "Invoke Required" property, etc). In order to use an "invoke" one has to have a delegate or use control.invoke(); unfortunately, the compiler cannot create a delegate based on a name it cannot check at "compile time", e.g., you can't use a variable and create the delegate at run time (as far as I have found out). Yes, it is difficult to gain addressability to the delegate if it's in the 'forms' class, since the forms class, many times is the 'main()' class and starts the other threads, but not always. Good code dictates that you really don't want any cross-thread meddling if you can avoid it. Trying to acquire a delegate from the UI class/thread for your use in another class/thread is very dangerous. Again, one has to resort to all sorts of reflection tricks to try to get the field. 4) This is made more confusing in that .NET mangles the names for things, such as events associated with forms 'field' changes, but adding the word 'changed' to the name. If you don't know this, and it's not well documented, you can miss the boat forever trying to get an eventhandler hooked in to deal with the notification of the value changed. 5) .NET will consistently give you "invalid operation" and "illegal cross thread call" exceptions EVEN IF you handle the problem in the set accessor for the forms textfield/whatever. This has to be solved by changing the property named "CheckForIllegalCrossThreadCalls" to 'false' instead of the default 'true'. Obviously, this should never be done unless you have code in the set accessor to deal with Xthread calls, but if you do, you still have to find this property and change it to false. This is very poorly documented also. I'm sure that many people have sorted out this problem in real-world applications. I would think, for instance, that many progress bars are the result of cross-thread updating, but I'm not privy as to how they've solved the problems. I took the time to respond because I have pursued this diligently over the last couple of weeks, and I have yet to find anyone that has addressed the whole set of issues in a concrete, concise manner, and providing sample code THAT WORKS. 'nuff said Tom

  I'm not sure you're discussing the same thing. The cross-thread operation exception occurs when you try and access a Form property or method from the wrong thread. In this case you already know the form--there's no need to "find the control you're interested in" or involve Reflection at all.

  If you're going out of your way to find some control to then find a propery to decide whehter Invoke is required, you're missing the point. You're only concerned with InvokeRequired if you are already accessing Form data; there's no other reason to be concerned with InvokeRequired. Accessing Form properties (InvokeRequired included) is not a "long drawn-out process" at all in this case

  Maybe if you provide some sample code where you're having problems, someone can offer some guidance. I'm assuming this involves Compact Framework code

  
  
  
• Cross-thread operation not valid