我遇到了PushFrame
Dispatcher
对象的public void PushFrame(DispatcherFrame frame)
{
// Stuff
_frameDepth++;
while(frame.Continue)
{
// Getting and dispatching messages
}
_frameDepth--;
// Stuff
}
方法。它是方法的简化版本:
PushFrame
换句话说,它只是打开新的消息处理循环。但我真的无法理解这种方式的好处。出于什么目的使用{{1}}?它的用法有很好的例子吗?至于我,似乎这种方法会导致不明显的错误。
答案 0 :(得分:10)
这是WPF程序中调度程序循环的必要管道。 Windows上的每个GUI程序都有一个,它是producer-consumer problem的通用解决方案。操作系统和其他程序生成的地方以及WPF程序的UI线程消耗。对GUI应用程序的硬性要求,实现GUI的库代码从不是线程安全的。你可以在这里轻松看到循环,你看不到循环清空的线程安全队列,它内置在操作系统中。
通过调用Application.Run()启动循环。在WPF应用程序中不容易看到,它是在App.xaml文件的大多数应用程序中自动生成的。推动第一个“框架”,只要它停留在循环内,你的应用程序就会继续运行。在事件处理程序上设置断点时,您将始终在“调用堆栈”调试器窗口中看到它。关闭应用程序的MainWindow是循环结束的正常方式。这反过来导致Run()方法返回,终止UI线程,终止进程。
在某些情况下,您希望拥有嵌套的调度程序循环。一个“模态循环”。您每天使用的这种模态循环的一个示例是当您在窗口角上单击并拖动鼠标时。现在,所有鼠标和键盘输入都会更改窗口大小或位置,它们不再用于以正常方式操作UI。释放鼠标会终止该循环。这个调度程序循环内置在操作系统中,它不是由WPF完成的。
但WPF也用于这种模态循环。规范示例是Window.ShowDialog()
方法。在关闭对话框之前,该方法不会返回。由WPF内部再次调用PushFrame()实现。只需使用调试器进行尝试,您将在“调用堆栈”窗口中看到两个PushFrame调用。第一个是ShowDialog()调用的那个,第二个是Application.Run()调用的那个。如果您的对话框依次显示对话框,您将获得更多。
一个不太明显的例子是在UI线程上调用Dispatcher.Invoke()。在调用的方法返回之前不返回的方法。通常有点像一个bug,但没有令人信服的理由不允许它。警告可能是恰当的,模态循环非常危险。他们有诀窍导致 re-entrancy bug 。使DoEvents()方法如此臭名昭着的错误。 ShowDialog()禁用UI中所有其他窗口的一个重要原因。
答案 1 :(得分:1)
PushFrame用于什么目的?
它内部用于将帧推送到当前调度程序。调度程序队列的详细工作原理是一个很大的主题,但以下答案应该会有所帮助。
Understanding the Dispatcher Queue
是否有很好的使用示例?
例如,当您出于某种原因想要同步调用异步方法并继续抽取消息,直到任务完成。您将在GitHub上的Stephen Cleary的AsyncCTPUtil库中找到具体的示例实现:https://github.com/StephenCleary/AsyncCTPUtil/blob/master/AsyncTestUtilities/WpfContext.cs
请参阅此处的回答以获取更多信息: