2

我正在尝试实现一个将自身注册为 DDE 服务器的应用程序，以便它正确响应我们的自定义“.qsx”文件类型，就像 WinWord 响应“.docx”文件类型一样。

IE

  1. 如果应用程序已经在运行并且有人双击“.qsx”文件，那么我们希望已经打开的应用程序接收 DDE 打开命令并打开相关文件。
  2. 但是，如果应用程序尚未运行，那么 shell 应该启动我们的应用程序，然后与应用程序建立 DDE 连接并告诉它像以前一样打开文件。

我们的第 1 部分工作完美。

但是，对于第 2 部分，Shell 启动命令，但随后失败并显示“将命令发送到程序时出现问题”。这对应于从“ShellExecute”Windows API 函数返回的返回代码“SE_ERR_DDEFAIL”(29)。

事实上，我已经编写了一个名为“ShellExecute.exe”的自定义控制台应用程序，它可以完全独立于 explorer.exe 来重现这个问题。

如果我运行 ShellExecute.exe 并且我们的“DDE 服务器”应用程序已经启动，那么它可以正常工作。如果我为“.docx”文档运行 ShellExecute.exe 而 WinWord 没有运行，WinWord 会正确启动并加载该文档但在我们的服务器应用程序甚至有机会注册为 DDE 服务器之前，立即返回 SE_ERR_DDEFAIL。

出于某种原因，对于 WinWord，ShellExecute 似乎等待它启动。

我尝试在运行 procmon.exe 的情况下运行这两种情况，以查看 ShellExecute 可能在注册表中查找的内容，从而将我们的情况与 WinWord.exe 区分开来，但我找不到任何东西。

我真正需要的是 ShellExecute 算法的源代码，这样我就可以找出为什么它适用于 WinWord 但不适用于我们的自定义扩展。

谁能详细解释一下 ShellExecute 启动应用程序时做了什么，特别是它如何知道“等待”应用程序注册为 DDE 服务器？

4

2 回答 2

5

在 XP+ 上运行的应用程序应该使用 IDropTarget以避免 DDE 出现挂起窗口时的问题。

使用 DDE 时，shell 假定您的 DDE 服务器在您开始消息循环之前已启动并正在运行...

于 2011-10-29T17:35:50.163 回答
0

请不要使用 DDE。这是一种荒谬的过时方式，它会导致各种问题并挂起并依赖于注册表。

执行此操作的现代方法是使用全局互斥锁。如果你搜索 Stack Overflow，你会发现很多人都在问同样的问题（也许从这里开始）

于 2011-10-28T19:20:22.187 回答