优化自动折叠逻辑稳定性、引入 UI 补救机制并增强日志系统

[PANDAJSR]

1. 核心逻辑重构与稳定性增强

   • 逻辑解耦与清理：重构了 MW_Timer.cs 中原本冗长且难以维护的软件判断逻辑，通过封装提高了代码的可读性，去除了冗余的条件分支。
   • 新增 UI 补救机制 (UI Rescue)：针对侧边栏可能出现的“逻辑上已收纳但 UI 仍残留在屏幕内”的边缘情况（Bug），新增了实时 UI
     边距检测。若检测到状态不一致，将强制重新执行收纳动画，大幅提升了 UI 表现的可靠性。
   • 线程安全优化：在访问 UI 元素（如 ViewboxFloatingBar.Margin）时引入了 Dispatcher.Invoke，确保在定时器线程中进行跨线程操作时的安全性。

2. 交互鲁棒性提升

• 操作拦截与防抖：在 MW_AutoFold.cs
  中完善了状态锁判断，严格限制了在收纳/展开动画播放期间的重复触发，避免了因用户快速点击或短时间内多次触发导致的动画重叠和逻辑混乱。

3. 增强的调试与异常监控

• 上下文感知日志：新增了详尽的 Trace 日志，记录包括：当前前台进程、窗口标题、实时 UI
  物理边距以及自动折叠的识别结果。这为后续排查特定软件环境下的自动折叠失效提供了精确的数据支持。
• 异常捕获明晰化：将原本静默捕获的异常改为记录详细错误信息，确保在出现系统级调用错误时不再“无迹可寻”。

---

1. 旧版逻辑 (origin/beta)：冗余且“各管各的”
   旧版的逻辑像是一个不断打补丁的列表，通过一个巨大的 if-else if 链来运行：

• 检测方式：
  1. 先看有没有全屏窗口。如果有，直接收纳并退出。
  2. 如果没有全屏，进入一个长达几百行的列表：
     • 如果是希沃 5（判断版本号、判断是否是标注模式...）。
     • 如果是希沃 3（判断版本号...）。
     • 如果是鸿合展台、鸿合白板、微软白板、MaxHub...（每一个软件都写了一遍类似的检测逻辑）。
• 达成条件：
  • 当前进程名 == 目标进程 且 窗口高度/宽度满足全屏条件 且 设置里开启了该项。
• 存在问题：
  • 代码重复：几乎每个软件都在重复写同样的“判断窗口大小”和“判断是否收纳”的代码。
  • 逻辑死角：如果逻辑上认为收纳了（isFloatingBarFolded = true），但因为 Windows 系统的原因动画没跑完或者 UI
    没藏好，旧逻辑会直接跳过，导致侧边栏“卡”在屏幕中间。
  • 黑盒运行：运行过程中没有日志，不知道到底是没检测到窗口，还是判断条件没达成。

2. 新版逻辑 (beta)：统一判断 + UI 补救
   新版通过“逻辑解耦”将检测和执行分开了：

• 检测方式（统一化）：
  1. 状态预聚合：一上来先收集所有信息：进程名、标题、全屏状态、UI 实际边距、识别逻辑结果 (CheckShouldAutoFoldByWindowPreview)。
  2. 日志先行：在做任何决定前，先打印一条 Trace 日志，记录当前环境的所有参数。
• 核心逻辑变化：
  • 条件 1：全屏优先 + 强制补救
    • 如果有全屏目标 -> 若未收纳则收纳。
    • [新增补救条件]：若逻辑显示已收纳，但 UI 实际左边距 > -50（即还在屏幕里）-> 说明 UI 卡住了，强制重新执行收纳动画。
  • 条件 2：统一目标识别
    • 直接调用 CheckShouldAutoFoldByWindowPreview()（它包含了原来那几百行的逻辑）。
    • 只要它返回 true，且用户最近没手动展开过 -> 触发收纳。
  • 条件 3：异常恢复
    • 增加 try-catch 记录具体的系统异常（如获取进程名失败），而不是像以前那样直接静默崩溃。

为什么要合并这些更改？
本次修改主要解决了之前在频繁切换前台窗口的情况下有概率不能正确触发自动收纳，并显著增强了代码的健壮性和可调试性。

[PANDAJSR]

依旧vibe

[PANDAJSR]

QQ20260204-102401-HD.mp4

演示视频，可以看到没有卡出bug，而且非授课状态（非全屏）的希沃白板是不会触发的，全屏状态的希沃白板无需在前台也可以触发自动收纳，在实际使用中也通常希望是这样