摆脱ShellExecute引起的邪恶延迟

kor*_*ona 3 c++ winapi shellexecute

这是困扰我一段时间的事情,只需要解决这个问题.每次我调用ShellExecute来打开一个外部文件(无论是文档,可执行文件还是URL),这都会导致程序中的锁定很长,然后ShellExecute会生成新进程并返回.有谁知道如何解决或解决这个问题?

编辑:正如标签可能表明的那样,这是在使用C++的Win32上.

180*_*ION 9

我不知道是什么导致了它,但Mark Russinovich(sysinternal的名声)有一个非常好的博客,他解释了如何调试这些事情.一个值得关注的好处是延迟Windows Vista文件打开对话框的案例,他只使用进程资源管理器调试了类似的问题(结果是访问域的问题).你当然可以使用常规的Windows调试器来做类似的事情.

您的问题可能与他不一样,但使用这些技术可能会帮助您更接近问题的根源.我建议调用该CreateProcess调用,然后捕获一些堆栈跟踪并查看它似乎挂起的位置.

流程启动延迟的情况可能对您更有意义.


Aar*_*ark 3

你是多线程的吗?

我发现使用 ShellExecute 打开文件时出现问题。不是可执行文件,而是与应用程序关联的文件 - 通常是 MS Office。使用 DDE 打开文件的应用程序会向所有(好吧,我不知道是否是所有...)程序中的所有线程广播一些消息。由于我没有在应用程序的工作线程中泵送消息,因此我会将 shell(以及文件的打开)挂起一段时间。最终在等待我处理消息并且应用程序启动并打开文件时超时。

我记得在循环中使用 PeekMessage 来删除该工作线程队列中的消息。我一直认为有一种方法可以用另一种方式避免这种情况,也许以不同的方式创建线程,以免成为消息的目标?


更新 它一定不仅仅是任何正在执行此操作的线程,而是为窗口提供服务的线程。雷蒙德(链接 1)知道一切(链接 2)。我敢打赌 CoInitialize(单线程单元)或 MFC 中的某些内容为线程创建了一个隐藏窗口。

  • 如果一个线程有一个窗口,它必须泵送消息——这是 Windows 编程契约的一部分 (2认同)