Why doesn't a BackgroundWorker need Invoke in the ProgressChanged event handler?

混江龙づ霸主 提交于 2019-12-19 09:18:36

问题


Since the ProgressChanged event handler is raised from somewhere within the DoWork event handlers, shouldn't they be called on the asynchronous operation thread, which DoWork also runs on, instead of the UI thread, and therefore require Invoke or BeginInvoke to manipulate controls?

My guess is that some magic is happening within the ReportProgress method, but how does it even know, which one is the correct thread to invoke the ProgressChanged event handlers on?


回答1:


When you call RunWorkerAsync, the BackgroundWorker internally creates a new AsyncOperation associated with the current synchronization context, as retrieved through the AsyncOperationManager.SynchronizationContext static property.

This synchronization context would be an instance of a class deriving from SynchronizationContext. The specific type depends on the synchronization model provider your application uses. If you’re running Windows Forms, it would be WindowsFormsSynchronizationContext; on WPF; it would be DispatcherSynchronizationContext.

When you subsequently call ReportProgress on the background thread, the BackgroundWorker would internally call Post on the aforementioned SynchronizationContext instance, thereby dispatching the operation to the associated thread asynchronously.

In Windows Forms, this is implemented as a Control.BeginInvoke call; on WPF, it becomes a Dispatcher.BeginInvoke call.



来源:https://stackoverflow.com/questions/12121708/why-doesnt-a-backgroundworker-need-invoke-in-the-progresschanged-event-handler

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!