SummaryWindows Forms controls are generally not thread-safe (directly or indirectly inherited from system. windows. forms. control), so. NET framework to prevent the control from being accessed under multithread, which may lead to inconsistent control states, during debugging, CLR-debugger will throw an invalidoperationexception to 'recommend 'possible risks of the programmer program. What is the key to the problem? And the resulting adjustment of the programming model.
1. ExampleFirst, let's look at a code instance. The task to be completed in this example is triggered by the click of a button to start a thread (manual thread). The purpose of this thread is to complete the setting of the textbox's text property.
1.1 unsafe access to control
Code 1.1Using system; using system. configuration; using system. collections. generic; using system. componentmodel; using system. data; using system. drawing; using system. text; using system. windows. forms; using system. threading; using system. io; namespace windowsapplication1 {public partial class form1: FORM {public form1 () {initializecomponent ();} private void unsafesettextbutton_click (Object sender, eventargs E) {Thread settextthread = new thread (New threadstart (dowork); settextthread. Start ();} private void dowork () {string filename = ". \ test-src.txt"; if (! File. exists (filename) {MessageBox. Show (string. Format ("{0} doesn't exist! ", Filename)," filenofoundexception "); return;} string text = NULL; using (streamreader reader = new streamreader (filename, encoding. default) {text = reader. readtoend ();}
This. textbox1.text = text;}}} During debugging, the following dialog box is displayed in bold in the above Code: prompt, the thread of the current access control is not the thread (main thread) of the created control ).
1.2 What's mean?Of course, you can also ignore the invalidoperationexception. In a non-Debug state, this exception will not be thrown. CLR-debugger monitors possible inconsistent access to handle, the expected robust code is the real motive behind cross-thread operation not valid. However, there are two choices in front of us: first, in some cases, we do not need this kind of "suggestion", which will bring unnecessary trouble during debugging; second, compliant with the "good-intentioned" suggestion, which also means that we must adjust the effective and handy programming model (one of the costs), and this adjustment will also bring side-effect, at present, this side-effect is not clear about the simple and elegant solution (cost 2 ).
2. The first choice: checkforillegalcrossthreadcilsIgnore the cross-thread invalidoperationexception suggestion, provided that we do not need similar suggestions and do not want to cause too much trouble for debugging. Disable checkforillegalcrossthreadcils, which is a static property in the control class. The default value is flase. It is used to monitor whether handle may have inconsistent access; this setting has application scope. If you only need to remove cross-thread invalidoperationexception in some forms, you can set checkforillegalcrossthreadcils to false after initializecomponent statement in form. ctor.
Code 2.-1Public form1 () {initializecomponent (); control. checkforillegalcrossthreadcils = false ;}