Windows Forms中MessageBox弹出时Control.Invoke是否被阻塞？

1. MessageBox弹出时，updateUI是否会被阻塞？ #

是的，肯定会阻塞。原因如下：

• MessageBox.Show() 是模态对话框，它会接管UI线程的消息循环，同时禁用主窗体的消息处理能力。
• Control.Invoke() 是同步调用：它会向UI线程发送处理请求，然后阻塞当前回调线程，等待UI线程完成updateUI的执行才会继续。但此时UI线程被MessageBox的模态循环卡住，根本无法处理主窗体的Invoke请求，所以updateUI会一直挂起，直到用户关闭弹窗，直接导致bool变量无法及时设置。

2. 如何强制回调在弹窗期间执行？使用BeginInvoke是否可行？ #

使用BeginInvoke()是可行的，这是最直接的解决方案：

• Control.BeginInvoke() 是异步调用：它仅将updateUI的委托请求放入UI线程的消息队列，不会阻塞当前回调线程，回调方法可以直接继续执行（如果后续逻辑不依赖updateUI的执行结果）。
• 即便UI线程被MessageBox的模态循环占据，BeginInvoke的请求会在消息队列中排队，一旦MessageBox关闭，UI线程会立即处理该请求。如果bool变量必须和UI控件操作绑定（必须在UI线程设置），这是当前最合理的处理方式。

额外提示：如果该bool变量不是UI控件的属性，只是普通业务变量，你完全可以直接在回调线程中设置，无需Invoke——只要保证变量的线程安全（比如用lock或Interlocked类），完全不会受MessageBox的影响。

3. 为什么Windows.Forms.Timer能正常工作，换成System.Timers.Timer就不行？ #

两者核心运行机制完全不同：

• Windows.Forms.Timer：它的Tick回调直接在UI线程执行，依赖UI线程的消息循环。MessageBox弹出时，虽然主窗体被禁用，但MessageBox自身会运行一个消息循环，这个循环会处理WM_TIMER消息（Forms.Timer的底层实现），所以Tick回调能正常触发执行，自然可以处理UI更新和变量设置。
• System.Timers.Timer：它的回调在线程池线程执行，与UI线程完全分离。当你用Control.Invoke()同步请求UI线程处理时，由于主窗体被模态对话框禁用，UI线程无法处理该Invoke请求，导致回调被阻塞，变量无法及时设置。

内容的提问来源于stack exchange，提问作者Flipps