首页 > 代码库 > 跨线程访问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); }));