Once you go input-idle, your application is deemed ready to receive DDE messages

Feel free to stop using DDE.

There was one customer who confessed that they were still using DDE, and they asked for help debugging a DDE problem. They found that sometimes, when their application was launched for DDE, it never received the WM_DDE_INITIATE message. Instead, the Shell­Execute function returned ERROR_DDE_FAIL. If launched from Explorer, the error message shown to the user was "There was a problem sending the command to the program."

It took a long time to figure out what was going on, and there were a number of dead ends, but I'll cut to the chase: The problem was that one of the features they added to their program included code that ran during process startup, and that code pumped messages as part of its initialization. Message pumping was not expected there, which is why it took so long to isolate.

The Wait­For­Input­Idle function was created for DDE. It's how a DDE client determines that the DDE server is ready to accept commands. And as soon as any thread in your process goes input-idle, the entire process is declared to be input-idle, and you end up becoming eligible to receive DDE messages, even if you're not really ready for them.

In the case of this program, the accidental message pump caused the application to be considered ready to accept DDE commands even though the main DDE server hadn't gotten off the ground yet. The initiation message went to the splash screen, and the splash screen said, "Why are you bothering me with stupid DDE messages? I'm just a splash screen!"

TL;DR: If your application includes a DDE server, make sure not to pump messages until your DDE server is ready to receive commands.

Comments (11)
  1. Rick C says:

    Visual Studio sometimes gives this error if you double click on a source file in Explorer.  I wonder if this is why.

  2. Joshua says:

    @Rick C: Nah. That's because Visual Studio can go non-responsive.

  3. My takeaway says:

    tl'dr. Feel free to stop using DDE.

  4. Rick C says:

    @Joshua, even when it wasn't running?

  5. Hildar says:

    I get that error message if I double click an office (excel/word/powerpoint/etc.) file while the appropriate office2010 application is still starting up and displaying it's splash. I seriously hope that office 2010 isn't using DDE!

  6. Richard Moss says:

    I looked in to the registry for the "open as read-only" verb for Excel 2013 and was astonished to see it was still using DDE. I suppose if it ain't broken, don't fix it?

  7. Gabe says:

    Hildar: The idea is to reuse an existing Word/Excel/etc. process rather than creating a new one for each file being opened. What would you expect them to use, if not DDE?

  8. alexcohn says:

    @Gabe: The idea is to reuse an existing Word/Excel/etc. process rather than creating a new one for each file being opened.

    Is there a good reason to do this in 64-bit Windows?

    [The reasons for reusing are not really memory-related. They are architectural. For example, the object model exposes a single Application object. Also, you can switch to MDI mode. -Raymond]
  9. Joshua says:

    [Single application objecct]

    I'm pretty sure I didn't imagine new Microsoft.Office.Interop.Word.Application and I really don't want to step on the user's open copy when I spin one up to do with as I please anyway.

  10. immibis says:

    Is there a recommended way for applications to open documents in an existing process without DDE?

    Of course it can be done with various IPC mechanisms; I'm specifically asking if one is recommended.

  11. John Doe says:

    @immibis, use COM.  Explorer will use COM activation if you register your application for a file type with DropTarget (I think there are multiple places in the registry where you can do this), so your application will execute once if the class factory is registered with REGCLS_MULTIPLEUSE.

    See Raymond's entry "How do I accept files to be opened via IDropTarget instead of on the command line?"


    See MSDN entry "Application Registration" (in "File Types and File Associations")


    See the Shell SDK "DropTarget Verb Sample"


     It really is just a sample, e.g. you'd want to register the class factory as REGCLS_MULTIPLEUSE, you'd (un)register stuff in the registry at (un)installation time.

    @Raymond, I'm curious, did you author this sample?  The comments are actually quite good.

Comments are closed.