当前位置：首页 > news >正文

PLC没停稳，窗口先关了？WPF上位机异步退出拦截的最佳实践

news 2026/8/10 15:47:55

前言

在工控上位机开发中，软件的“退出”逻辑往往比“启动”更重要。

很多开发者都遇到过这种尴尬：用户随手点了个关闭（X），窗口瞬间消失，但此时：

通讯未断开：PLC 还在等待上位机的握手响应，导致设备报通讯故障。
数据正缓存：关键的历史数据、报警日志正处于异步写入数据库的中间态，程序直接没了。
设备未复位：关键的轴运动或加热指令还没来得及下发“停止”信号。

痛点在于：WPF 原生的OnClosing事件是同步的，而现代化的清理工作（断开 PLC、保存数据库）往往需要await异步执行。

今天分享一个非常巧妙的“状态位重入”模式，优雅地解决这个难题。

1. 深度解析：为什么常规写法会失效？

有些开发者尝试在OnClosing中使用async void，代码如下：

// 错误示范protected override async void OnClosing(CancelEventArgs e){ await _plc.StopAsync(); // 还没等这里执行完，窗口已经销毁了！}

由于async void是“发射后不管”，当程序运行到await时会立即返回，UI 线程会继续执行系统的关闭流程，窗口在异步任务完成前就已经被彻底 Dispose 了。

2. 优雅的解决方案：状态位重入法

我们要利用一个布尔变量作为“状态开关”，实现先拦截、后异步处理、最后真正释放的逻辑闭环。

第一步：定义异步拦截接口

为了符合 MVVM 模式，我们定义一个接口，让 View Model 拥有决定“能不能关”的权利。

public interface IAsyncClosing{ // 返回 true 允许关闭，返回 false 拦截关闭 Task<bool> OnClosingAsync();}

第二步：View 层的巧妙拦截

这是整套逻辑的核心。我们利用_isReallyClosing标志位来判断当前是“第一次拦截”还是“第二次放行”。

public partial class MainWindow : Window{ private bool _isReallyClosing = false; // 状态位 protected override async void OnClosing(CancelEventArgs e) { // 如果标记为“允许放行”，则走系统默认关闭流程 if (_isReallyClosing) { base.OnClosing(e); return; } // 1. 【核心】先拦住 WPF 关闭流程，不让窗口销毁 e.Cancel = true; // 2. 检查 VM 是否有异步清理逻辑 if (DataContext is IAsyncClosing closing) { // 此时 UI 线程不会卡死，可以显示“正在停机...”的动画 bool canClose = await closing.OnClosingAsync(); if (!canClose) return; // 如果逻辑判定不能关，直接返回 } // 3. 清理完成，设置状态位，手动触发 Close() _isReallyClosing = true; this.Close(); // 这一次进入 OnClosing 时，会触发上面的放行逻辑 }}

3. 为什么这种模式适合工控场景？