|Date:||June 21, 2006 / year-entry #207|
|Summary:||You too can use your psychic powers to debug the following problem: We have a problem with opening documents with our application by double-clicking them in Explorer. What's really strange is that if we connect a debugger to Explorer and set a breakpoint on kernel32!CreateProcessW, then wait a moment after CreateProcess returns, then hit 'g',...|
You too can use your psychic powers to debug the following problem:
If you've been reading carefully and paid attention to the explanation of how document launching via DDE works, then you already know what the problem is.
Recall that launching documents via DDE is done by first
looking for a DDE server and if none is found, launching
a server manually and trying again.
The command line above was clearly registered as the
Clearly, something is going wrong when Explorer attempts the second DDE conversation to open the document. The fact that making Explorer wait a few seconds fixes the problem makes the cause obvious: The DDE server is being slow to get itself initialized and listening. Explorer launches the server and tries to talk to it, but the server is not yet ready and therefore doesn't respond to the DDE initiate.
But how do you fix this?
The shell assumes that a DDE server is ready to accept connections
when it goes input idle.
Moral of the story: If you're going to act as a DDE server, make sure you do so before your primary thread starts pumping messages. Otherwise you have a race condition between your application startup and the shell trying to talk to it.
<-- Back to Old New Thing Archive Index