我有一个定制的 Windows 桌面应用程序，它在具有多个显示器的系统上的行为出乎意料地不同，具体取决于它的启动方式。我的期望是它对于每种启动方法的行为都应该相同。每种方法都涉及打开与应用程序关联的文件。
以下是我尝试过的启动方法和产生的行为：
在文件资源管理器中双击关联文件：
应用程序启动后，UI 会在文件资源管理器所在的显示器上打开，而不是在主显示器上打开，这已是设计初衷。尝试与应用程序交互时，部分 UI 也会丢失。
将关联文件拖放到文件资源管理器中的应用程序 exe 上：
应用程序在正确的显示屏上打开并正常运行。
通过运行以下命令从命令提示符启动该应用程序
name_of_application.exe "file_to_open"：应用程序在正确的显示屏上打开并正常运行。
在文件资源管理器中右键单击相关文件，然后选择“打开方式...”。浏览到已安装的应用程序并选择它：
一开始似乎什么都没有发生。大约 5 分钟后，应用程序在正确的显示屏上打开并正常运行。之后，再次打开相同的关联文件会导致方法 1-3 中描述的相同行为，再次取决于文件的打开方式。
我不确定这是否重要，但这是一个使用 WPF 框架编写的 .NET 应用程序，针对 .NET 4.7.2。这是一个 64 位应用程序。代码从 .NET 请求主显示器，该显示器对应于用户的系统显示设置。
我检查了文件关联的相关注册表项，似乎没有任何异常。请参见以下屏幕截图（关联文件类型为 .sejs）：
我还尝试从注册表中删除第二张图片中显示的“Command”值，这没有任何影响。据我所知，此文件关联并没有什么不寻常之处会导致此行为。
我也尝试过重建安装程序、修复安装并重新启动我的机器。
这让我想到了几个问题：
- 什么原因会导致 Windows 根据关联文件发送到应用程序的方式在不同的显示器上打开该应用程序？
- 如果我在将文件重新关联到该应用程序期间打开该应用程序，什么会导致 Windows 打开该应用程序时出现长时间延迟？
答案1
您描述的效果很大程度上取决于启动文件的系统调用。执行程序的 Windows API 调用有许多参数，因此这完全取决于相关的 Microsoft 程序员。
这种差异在 Windows 中很常见，因为 Windows 拥有由许多程序员编写的庞大代码库。由于 Windows 是一个封闭系统，因此必须了解这些差异并适应。您/我们无法“修复”Windows。