如何用Process.Start强制启动新进程以可靠追踪文档编辑退出状态

问题描述 #

用Process.Start()打开文件时，Notepad++、Acrobat Reader这类应用常复用已有进程打开新标签，导致无法通过Process对象的生命周期来可靠追踪文档的编辑状态和关闭事件——进程没退出，只是标签页关闭了。虽然部分应用支持特定命令行参数强制创建新进程，但需要通用的实现方案。

通用实现方案 #

1. 监控文件系统追踪编辑状态 #

直接监听目标文件的修改事件来判断是否被编辑：

• 使用FileSystemWatcher监听文件的Changed事件，注意过滤应用自动生成的临时文件、备份文件（比如Notepad++的.bak文件），避免误判。
• 记录文件初始的最后修改时间戳，每次触发事件时对比时间戳，确认是用户主动编辑而非应用的自动保存操作。

2. 监听窗口关闭事件追踪文档退出 #

通过Windows API定位文档对应的窗口并监听关闭消息：

• 调用Windows API枚举所有顶层窗口，结合窗口标题（通常包含文件名）或所属进程信息，匹配到目标文档的窗口。
• 使用SetWindowsHookEx注册钩子，监听窗口的WM_CLOSE消息；或者用RegisterWindowMessage自定义消息，当窗口关闭时触发回调。
• 注意：部分应用的标签页属于主进程的子窗口，需要额外枚举子窗口并监听其关闭事件（比如Notepad++的标签页窗口）。

3. 尝试通用参数强制启动独立进程 #

对支持多实例的应用，尝试通用启动参数：

• 常用参数如-multiInst（Notepad++）、/n（Acrobat Reader），也可以尝试/new、--new-instance这类通用格式。
• 配置ProcessStartInfo的UseShellExecute = false，直接启动应用程序并传入文件路径，部分应用会默认创建新实例。

4. 嵌入轻量编辑器实现完全掌控 #

如果外部应用的追踪方案不可靠，可在自有应用内嵌入编辑器：

• 文本文件用RichTextBox控件，PDF文件用开源渲染库（如PdfiumViewer），这样能完全掌控文档的编辑操作、保存状态和关闭事件。

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