非UI线程访问UI线程里的控件但不更新它需要invoke吗

Question

string str=label1.Text;
label1.Text="1";
你分别在线程里执行这两句话,看哪个报错误不就得了

Answer 1

简单的情况很可能看不出问题，不过winform无法保证取值是没有副作用的，所以理论上应该invoke才能确保正确。

Answer 2

访问的话，应该可以不用Invoke自己试下就知道了~

Answer 3

试了下还真不需要，甚至set时如果没有实际改变也不需要。。但靠这么分辨，写起代码来太麻烦了，还不如无脑invoke呢= =

Answer 4

// 把跨线程调用检查设置为false
// base.invoke 倒是可以不要，不过确实一个保险操作
Control.CheckForIllegalCrossThreadCalls = false;

Answer 5

这只是不检查了,不代表不会出现异常
好比代码里标记为unsafe,就可以用指针了一样,不代表这样用指针就不会溢出

Answer 6

几乎每个人都知道跨线程访问时，需要调用控件（或Form）的Invoke方法，其用途是将操作排入UI线程来执行；但又有多少人知道为什么要让UI线程来执行呢？你也可以设置CheckForIllegalCrossThreadCalls = false，不检查也不会抛出异常，但这是自欺欺人的做法，就和掩耳盗铃似的。你可以想象，同时有100个线程对同一个lable赋值，你能确定lable最终的值吗，你能保证线程都互不干扰不死锁吗？你能保证程序不会崩溃吗？Invoke就是解决此类问题的，其目的只有一个不管你有多少个赋值操作请排队。

Answer 7

既然是访问UI线程上的控件，最好还是使用Invoke或者beginInvoke教给UI线程来进行

Answer 8

取决于这个控件的这个属性的实现，Text是属性，也就是一个get_Text()方法
假如它就是简单的return this._text;这当然没问题，跟其他的类一样但是你无法确定某个控件，尤其是第三方自定义控件的get逻辑，假如它里面还有访问或者更新其他的东西，那么肯定就出问题了
同意LS的说法，更新界面和业务处理分开，处理完了把结果返回去，再更新界面