ISynchronizeInvoke与SynchronizationContext与mainForm.Invoke [英] ISynchronizeInvoke vs SynchronizationContext vs mainForm.Invoke

查看:88
本文介绍了ISynchronizeInvoke与SynchronizationContext与mainForm.Invoke的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个Worker类和一个MainForm/UI类.从UI类,我在新的后台线程中创建了Worker类的新实例.该线程将一些更新编组回UI控件.由于它们位于不同的类中,因此我基本上将MainForm实例(this)和适当的委托(用于更新控件)传递给worker类的构造函数.在构造函数中,我将mainForm设置为ISynchronizeInvoke对象(称为_synch),然后在worker类中进一步进行_synch.Invoke(theDelegate, new object[] { "new value" }).

I have a Worker class and a MainForm/UI class. From the UI class I create a new instance of the Worker class in a new background thread. This thread marshals a few updates back to the UI's controls. Since they are in different classes I basically pass the MainForm instance (this) and an appropriate delegate to update the controls, into the worker class' constructor. In the constructor I set the mainForm to an ISynchronizeInvoke object (call it _synch) and then, further down in the worker class I do _synch.Invoke(theDelegate, new object[] { "new value" }).

这一切都很好,但是后来我意识到也可以简单地执行mainForm.Invoke(不使用ISynchronizeInvoke对象).两者有什么区别?

That all works fine, but then I realized that it is also possible to do just simply mainForm.Invoke (not using the ISynchronizeInvoke object). What is the difference between the two?

更糟糕的是,我读过一篇文章,由于SynchronizationContext已经很长了,实际上不再需要ISynchronizeInvoke了.我意识到我不明白这两个是做什么用的.对于理解为什么我应该在这些对象上而不是直接在mainForm上使用Invoke的任何帮助,将不胜感激.

To make matters worse I read in an article that ISynchronizeInvoke is not really needed much anymore, now that SynchronizationContext has come a long. I realize that I do not understand what these two are for. Any help with understanding why I should use Invoke on these objects as opposed to directly on the mainForm would be greatly appreciated.

推荐答案

在Winforms中,无论您调用Form.InvokeISynchronizeInvoke.InvokeSynchronizationContext.Send哪种方法,您都在做同样的事情.

In Winforms, No matter what method you call Form.Invoke, ISynchronizeInvoke.Invoke, SynchronizationContext.Send you are doing the same thing.

实际上,它们内部都使用与Control.Invoke相同的方法(实现ISynchronizeInvoke接口成员).

In fact they all internally goes to the same method which is Control.Invoke(which implements ISynchronizeInvoke interface member).

两者(Form.Invoke和ISynchronizeInvoke.Invoke)有什么区别?

What is the difference between the two(Form.Invoke and ISynchronizeInvoke.Invoke)?

没什么,他们都指向相同的方法Control.Invoke.

Nothing, they are pointing to same method Control.Invoke.

也就是说,如果您依赖ISynchronizeInvoke,则在将应用程序移植到另一种技术(例如WPF)时会感到痛苦.那里不支持ISynchronizeInvoke.这是Winforms特有的东西.您应该始终偏爱SynchronizationContext.

That said, if you depend on ISynchronizeInvoke you'll feel the pain when you're porting the application to another technology (say WPF). ISynchronizeInvoke is not supported there. It is the Winforms specific thing. You should always favour SynchronizationContext over anything.

SynchronizationContext提供了抽象,无论采用何种技术,您都可以通过SynchronizationContext封送对UI线程的调用(通常不是总是如此).如果您的代码依赖于SynchronizationContext,则可以轻松地移植到WPF或Asp.Net,因为它们提供了特定于SynchronizationContext的技术实现.

SynchronizationContext provides the abstraction, whatever the technology may be, you can marshal the call to UI thread(typically not always) via SynchronizationContext. If your code depends on SynchronizationContext you can port to WPF or Asp.Net easily as they provide their technology specic implementation of SynchronizationContext.

  • Winforms实现-WindowsFormsSynchronizationContext
  • Wpf/Silverlight实现-DispatcherSynchronizationContext
  • Asp.net实现-AspNetSynchronizationContext

SynchronizationContext的一个缺点是它无法获取返回值,尽管您可以通过闭包,实例成员等来解决它.

One disadvantage of SynchronizationContext is that it provides no way to get the return value, though you can workaround it via closures, instance members etc.

进一步阅读:这全都是关于SynchronizationContext

这篇关于ISynchronizeInvoke与SynchronizationContext与mainForm.Invoke的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆