CODEWITHSUNDEEP
c++winapishellexecute
korona
korona

Reputation: 2229

Getting rid of the evil delay caused by ShellExecute

This is something that's been bothering me a while and there just has to be a solution to this. Every time I call ShellExecute to open an external file (be it a document, executable or a URL) this causes a very long lockup in my program before ShellExecute spawns the new process and returns. Does anyone know how to solve or work around this?

EDIT: And as the tags might indicate, this is on Win32 using C++.

Upvotes: 5

Views: 3072

Answers (3)

marler8997
marler8997

Reputation: 129

I also recently found an issue around ShellExecute. I was able to determine that ShellExecute will drop messages from the Window Message Queue. I've submitted a question about it here. It's possible this could explain why your program has delays. ShellExecute is probably dropping messages from the queue because it's calling GetMessage or PeekMessage itself and could be dropping messages that are meant for your window needed to be able to respond. For me I've solved the issue by using "CreateProcess" with "cmd.exe /c start ..." instead.

Upvotes: -1

Aardvark
Aardvark

Reputation: 8561

Are you multithreaded?

I've seen issues with opening files with ShellExecute. Not executables, but files associated an application - usually MS Office. Applications that used DDE to open their files did some of broadcast of a message to all threads in all (well, I don't know if it was all...) programs. Since I wasn't pumping messages in worker threads in my application I'd hang the shell (and the opening of the file) for some time. It eventually timed out waiting for me to process the message and the application would launch and open the file.

I recall using PeekMessage in a loop to just remove messages in the queue for that worker thread. I always assumed there was a way to avoid this in another way, maybe create the thread differently as to never be the target of messages?

Update It must have not just been any thread that was doing this but one servicing a window. Raymond (link 1) knows all (link 2). I bet either CoInitialize (single threaded apartment) or something in MFC created a hidden window for the thread.

Upvotes: 3

1800 INFORMATION
1800 INFORMATION

Reputation: 135245

I don't know what is causing it, but Mark Russinovich (of sysinternal's fame) has a really great blog where he explains how to debug these kinds of things. A good one to look at for you would be The Case of the Delayed Windows Vista File Open Dialogs, where he debugged a similar issue using only process explorer (it turned out to be a problem accessing the domain). You can of course do similar things using a regular windows debugger.

You problem is probably not the same as his, but using these techniques may help you get closer to the source of the problem. I suggest invoking the CreateProcess call and then capturing a few stack traces and seeing where it appears to be hung.

The Case of the Process Startup Delays might be even more relevant for you.

Upvotes: 9

Related Questions