C # about "Invalid thread operation: Access it from a thread that is not creating a control" __c#

Excerpt from: http://blog.csdn.net/hongkaihua1987/article/details/7439231
Http://hi.baidu.com/jcserver/blog/item/b7e8da3e2f6f35f0828b13f1.html
Classic resolution "Invalid thread operation: Access it from a thread that is not creating a control"
In programming, you often encounter complex operations in one button and add the last value of a complex operation to a ListView or ComboBox candidate. This time the program will card, and when the programmer puts the card code into thread (threads), it discovers that "the thread operation is invalid when the control is manipulated: it is not accessed by the thread that created the control" exception.
why. NET does not allow us to manipulate controls across threads, which is beneficial. Because if you have more threads, the deadlock occurs when two of threads try to change a control to its own state at the same time. But is that why we just let the program get stuck? Of course not, here we teach you two solutions:
(1) Do not use a delegate: In the constructor or form load code, add the following sentence:
Control.checkforillegalcrossthreadcalls = False
(2) Implementation of the method of entrustment
delegate void Settextcallback (string text);
Event Settextcallback Settextevent;
Calling functions in a form to pass arguments with invoke
private void SetText (string text)
{
if (this.txtShow.InvokeRequired)
{
Settextcallback d = new Settextcallback (SetText);
This. Invoke (d, new object[] {text});
}
Else
{
This.txtShow.Text + = text+ "\ n";
}
}
Settextevent + = new Settextcallback (SetText);
SetText (str);
(3)
This. Invoke (New MethodInvoker (displayreceivemessage));
private void Displayreceivemessage ()
{txt_visble. Text = "Hello World"}
==================================================================================
The following detailed explanation comes from:
Http://hi.baidu.com/jcserver/blog/item/b7e8da3e2f6f35f0828b13f1.html
In the design in order to let the interface and logic separation, my approach is to use events, the interface as long as the response to the event to deal with the display of the interface. Events can be thrown by different threads in a logical process, and the response method of these events throws an exception when modifying the contents of the controls in the interface.
Then the control.invokerequired attribute and invoke method are used.
MSDN says:
Gets a value that indicates whether the caller must call the Invoke method when it makes a method call to the control, because the call is in a thread other than the thread on which the control is created.
True if the control's Handle is created on a different thread from the calling thread (which indicates that you must invoke the control through the Invoke method), or false.
Controls in Windows forms are bound to a specific thread and do not have thread security. Therefore, if you call a control's method from another thread, you must marshal the call to the appropriate thread by using an invoke method of the control. This property can be used to determine whether the Invoke method must be invoked, which is useful when it is not known what thread owns the control.
Here's how to use this (my general practice):
You first define a delegate, which is the same as the signature of this event handler, and of course the delegate that uses the event directly is also possible, such as:
Private delegate void Invokecallback (string msg);
The value of this property is then judged to determine whether to invoke the Invoke function:
void M_comm_messageevent (String msg)
{
if (txtmessage.invokerequired)
{
Invokecallback msgcallback = new Invokecallback (m_comm_messageevent);
Txtmessage.invoke (Msgcallback, new object[] {msg});
}
Else
{
Txtmessage.text = msg;
}
}
Description: This function is the event handler function, Txtmessage is a text box.
This makes the thread safety of the controls on the form.