使用 WPF 应用程序的 UI 线程对 UI 元素执行长时间处理任务，同时更新同一窗口上的进度条
我的程序由一个大型图形 UI 控件组成，我需要每隔一段时间花大约 15 秒重新加载它。因为更新代码主要与 UI 控件一起工作（也许 90% 的代码实际上设置了控件的属性），所以对我来说，实际上让 UI 线程处理它是有意义的。我真的不希望控件在与 UI 分开的线程中加载时在视觉上重新绘制。
我还希望更新位于同一应用程序窗口的状态栏中的进度条。在这种情况下，有没有办法打破规则并仅重新绘制进度条，或者我应该打开一个新的应用程序窗口来放置进度条？
在这种特殊情况下你会怎么做？
My program consists of a large graphing UI control that I need to spend about 15 seconds re-loading every once in a while. Because the updating code works primarily with the UI control (maybe 90% of it actually sets properties on the control), it would make sense to me to actually let the UI thread handle that. I really don't want the control to visually re-paint while it is loading in a separate thread from the UI.
I also want a progress bar to update as well that lives in the status bar of the same application window. Is there a way to break the rule in this case and re-paint only the progress bar, or should I just open a new application window for the progress bar to live in?
What would you do in this particular case?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您可以将主要任务（即更新图表）分解为多个步骤，则可以将每个步骤作为单独的调度程序消息执行。这将允许处理其他消息，包括使您能够更新进度信息。
基本模式是：
然后，您可以在代码中的适当位置添加正在进行的更新。
附言。并不是说这是你最好的选择——在不了解所有细节的情况下很难判断。但这是一个选择。
If you can break your primary task (ie. updating the graph) in many steps, you can perform each step as a separate dispatcher message. This will allow other messages to be processed, including giving you the ability to update progress information.
The basic pattern is:
You can then add in progress updates at the appropriate points in your code.
PS. Not saying this is your best option - hard to tell without knowing all the details. But this is an option.
事实上，一个 UI 线程中只有一个 UI 线程是不正确的。 application，只是大多数 Windows 应用程序只在一个线程中创建 UI 对象，因此该线程成为应用程序中的“the”UI 线程。原因很容易理解 - 这使得代码更容易理解，并保护我们免受控件之间隐式线程绑定问题的影响。
这提出了一个可能的想法，如果事实证明不可能提高更新控件的速度（这是我建议首先要做的）。在单独的线程上创建 UI 控件。您需要确保该线程适合 UI，也就是说，线程模型是 STA，并且它会泵送消息，并且在控件被销毁之前不会死亡。我不知道您是否还需要在 UI 线程中创建父窗口，或者只是控件，但可能值得在这里进行试验。
It is not really true that there is only one UI thread in an application, it is just that most windows applications only ever create UI objects in one thread so this thread becomes "the" UI thread in the application. It is easy to understand why - this makes the code simpler to understand, and protects us from implicit thread binding issues between controls.
This suggests a possible idea, should it prove impossible to improve the speed of updating the control (which is what I would suggest to do first). Create the UI control on a separate thread. You need to make sure that the thread is suitable for UI, that is to say the threading model is STA, and that it will pump messages and not die before the control is destroyed. I don't know if you need to create the parent window in the UI thread as well, or just the control but it may be worth experimenting here.
寻找更高效的图形 UI 控件。除非 UI 线程屈服于消息循环，否则任何其他更新都不会发生（并且会减慢图形控件的更新速度）。
Find a graphing UI control that is more efficient. Unless the UI thread yields to the message loop any other updates won't happen (and it will slow down your graph control's updates).
我建议在新窗口中使用进度条（没有表单标题）。通过读取图形控件的共享属性使其绘制进度条。这样您可以避免线程阻塞（加载缓慢）。并且它为您提供良好的视觉体验（两个控件上的渐进式绘画）。
I would suggest using a progressbar in a new window (without the form headers). Make it paint the progress bar by reading the shared properties of a graph control. this way you can avoid the thread blocking (sluggish loading).. And it gives you good visual experience (progressive painting on both the controls).