为什么不控制更新刷新中间过程

为什么不控制更新/刷新中间过程

如果您正在UI线程上进行 处理
，则在处理运行时它将无法执行其他任何 *** 作（例如重新绘制更新的标签）。因此，例如，如果处理是由于用户单击按钮而发生的，并且是由按钮单击处理程序触发的（没有将其显式放置在另一个线程上），则该处理在UI线程上运行。即使您更新了标签的文本，也不会在收到画图消息之前将其绘制出来，此时，它可能正在忙于处理。

答案是在单独的线程上进行长时间运行的处理。hack（IMHO）

Application.DoEvents

用于使UI线程在处理过程中执行一些UI任务。如果在更新标签后且开始处理之前放入其中之一，则标签被重新粉刷的几率非常高。但是，在处理过程中，再也无法处理任何绘画事件（当有人将另一个应用程序窗口移到您的应用程序上并向后移动时，将导致半绘制窗口）。因此，我称其为hack（尽管，呃，嗯，我已经知道这样做了：-)）。

*根据您的修改进行 *编辑 更新：

回覆

因此，我猜想“处理”正在UI线程上进行，但是eventhandler在它自己的线程上被调用…

我假设

DoSomeProcess

是从UI线程触发的（例如，直接响应按钮单击或类似 *** 作）。如果是这样，那么可以，您的处理肯定在UI线程上。因为

TriggerProcessStarted

您是通过
异步
触发您的回调的

BeginInvoke

，所以您不知道何时运行该回调，但是无论如何您的代码都会立即启动处理，而不会屈服，因此没有其他人能够抓住该线程。由于这是UI线程，因此对委托的

Invoke

调用将在设置标签文本的调用中阻止，此后它必须等待UI线程（正在忙于处理）。（并且这是假设它安排在不同的线程上；我无法100％相信自己的任何一种方式，因为微软有两种不同的方式

BeginInvoke

s-IIRC的一位设计师已经承认这是一个非常愚蠢的想法-
自从我与这些东西战斗以来已经有一段时间了。）

如果您

TriggerProcessStarted

同步进行对回调的调用，则可以。但是，理想情况下，应在自己的线程上安排处理（如果不执行UI）。