首页 > 代码库 > 跨线程访问UI控件时的Lambda表达式
跨线程访问UI控件时的Lambda表达式
工作中经常会用到跨线程访问UI控件的情况,由于.net本身机制,是不允许在非UI线程访问UI控件的,实际上跨线程访问UI控件还是 将访问UI的操作交给UI线程来处理的,
利用Control.Invoke方法,将操作传递给UI线程,不推荐使用CheckForIllegalCrossThreadCalls = false;
Control.Invoke的签名
//
// 摘要:
// 在拥有此控件的基础窗口句柄的线程上执行指定的委托。
//
// 参数:
// method:
// 包含要在控件的线程上下文中调用的方法的委托。
//
// 返回结果:
// 正在被调用的委托的返回值,或者如果委托没有返回值,则为 null。
[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]
public object Invoke(Delegate method);
但是如果我们利用Lambda表达式的时候,编译会报错。
如:
this.Invoke(() => { this.panel1.Controls.Remove(ucLoading); });
编译报错:无法将Lambda表达式转为System.Delegate类型,因为他不是委托类型
The problem the user is seeing is that the Thread ctor accepts a specific delegate -- the ThreadStart delegate. The C# compiler will check and make sure your anonymous method matches the signature of the ThreadStart delegate and, if so, produces the proper code under-the-covers to create the ThreadStart delegate for you.
But Control.Invoke is typed as accepting a "Delegate". This means it can accept any delegate-derived type. The example above shows an anonymous method that has a void return type and takes no parameters. It‘s possible to have a number of delegate-derived types that match that signature (such as MethodInvoker and ThreadStart -- just as an example). Which specific delegate should the C# compiler use? There‘s no way for it to infer the exact delegate type so the compiler complains with an error.
也就是说,对于Thread 构造函数来说,由于接受的是一个ThreadStart委托,编译器便可以将匿名函数与ThreadStart委托类型匹配,最后能够正确编译。
而对于Control.Invoke()来说,任何的代理类型都是可接受的,也就是说ThreadStart和MethodInvoker都是可以接受的类型。这样编译器反而不知道应该用哪个代理去匹配匿名函数了,导致了编译错误的发生。
我们就得加个委托名了
this.Invoke(new Action(() => { this.panel1.Controls.Remove(ucLoading); }));
或者
this.Invoke(new MethodInvoker(() => { this.panel1.Controls.Remove(ucLoading); }));