DDE：实现通过Shell和ddeexec正确启动的应用程序

Question

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

即

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正确启动并加载文档 如果我为我们的“.qsx”文档运行ShellExecute.exe并且我们的应用程序未运行，则ShellExecuteEx启动应用程序但立即返回SE_ERR_DDEFAIL，之后我们的服务器应用程序甚至有机会注册为DDE服务器

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

我已经尝试运行procmon.exe运行这两个案例，看看ShellExecute可能在注册表中寻找的区分我们的案例和WinWord.exe，但我找不到任何东西。

我真正需要的是ShellExecute算法的源代码，以便我可以找出它为WinWord工作的原因，而不是我们的自定义扩展。

任何人都可以详细解释ShellExecute在启动应用程序时所做的工作，特别是它知道如何“等待”应用程序注册为DDE服务器吗？

Answer 1

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

使用DDE时，启动消息循环之前，shell assumes您的DDE服务器已启动并运行...

Answer 2

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

现代的方法是使用全局互斥锁。如果你搜索Stack Overflow，你会发现很多人都在问同一个问题（maybe start here）