Избавление от злой задержки, вызванной ShellExecute

Question

Это то, что беспокоило меня некоторое время, и просто должно быть решение этого. Каждый раз, когда я вызываю ShellExecute, чтобы открыть внешний файл (будь то документ, исполняемый файл или URL), это вызывает очень длительную блокировку в моей программе, прежде чем ShellExecute запускает новый процесс и возвращает его. Кто-нибудь знает, как решить или обойти это?

РЕДАКТИРОВАТЬ: И, как теги могут указывать, это на Win32 с использованием C ++.

Answer 1

Я не знаю, что является причиной этого, но у Марка Руссиновича (из славы sysinternal) есть действительно отличный блог, где он объясняет, как отлаживать подобные вещи. Хорошим примером для вас будет Случай с отложенными диалоговыми окнами открытия файлов Windows Vista , где он отлаживал аналогичную проблему, используя только проводник процессов (это оказалось проблемой при доступе к домену). Конечно, вы можете делать подобные вещи, используя обычный отладчик Windows.

Ваша проблема, вероятно, не совпадает с его, но использование этих методов может помочь вам приблизиться к источнику проблемы. Я предлагаю вызвать вызов CreateProcess, а затем захватить несколько следов стека и посмотреть, где он кажется зависшим.

Случай задержек с запуском процесса может быть еще более актуальным для вас.

Answer 2

Вы многопоточный?

Я видел проблемы с открытием файлов с ShellExecute. Не исполняемые файлы, а файлы, связанные с приложением - обычно MS Office. Приложения, которые использовали DDE для открытия своих файлов, делали передачу сообщений всем потокам во всех (ну, я не знаю, было ли это все ...) программами. Поскольку я не закачивал сообщения в рабочие потоки в своем приложении, я на некоторое время повесил оболочку (и открывал файл). В конечном итоге истекло время ожидания обработки сообщения, и приложение запустится и откроет файл.

Я помню, как использовал PeekMessage в цикле, чтобы просто удалить сообщения в очереди для этого рабочего потока. Я всегда предполагал, что есть способ избежать этого по-другому, может быть, создать поток по-другому, чтобы никогда не быть целью сообщений?

---

Обновление Должно быть, это был не какой-то поток, который делал это, а один, обслуживающий окно. Раймонд (ссылка 1) знает все (ссылка 2) . Могу поспорить, что CoInitialize (однопотоковая квартира) или что-то в MFC создали скрытое окно для потока.