The Old New Thing

Does anyone know what this setting is good for? I'm just curious. The excel help didn't contain any hints...

That option seems a bit ill-conceived and I doubt many users will see the connection.

I guess the Excel team will reconsider it? Alternatively switch the .xls registration to use an old-fashioned command-line parameter rather than DDE? (at least if that option has been set)

Isn't DDE deprecated? I thought Microsoft would migrate more smoothly, replacing ddeexec with something like mutex and IPC methods. It seems the product only get the job half done.

I'm not convinced that is the only answer. I've experienced the problem detailed in today's post and I did not have the 'ignore DDE requests' option ticked. I also get the same problem from Word which doesn't have that option and a similar error message from outlook 2007 opening a hyperlink even though the hyperlink is successfully opened.

Any chance you could point me at a copy of ddespy so I can investigae further. I've tried searching but the results are either spyware reports on the exe itself or dead-end visual C++ 6 documents with no download link. It looks like the tool has been withdrawn.

I often got this error with Word too, but never touched this option... Maybe it gets activated automatically in some cases ?

I find (with I think Office 2000, it may have been fixed in later versions) that it's usually due to Windows Installer. The first time that an Office app tries to run under a user account, it wants to do some installation stuff for some reason. But if you don't have the installation disk handy, you can click Cancel on each of the Windows Installer dialogs and then the program starts and appears to function normally.

But if the reason you opened it was double-clicking a file, the Windows Installer stuff seems to intercept the DDE call, so the file doesn't open (and I think Explorer gives a message about there being an error opening the file). But once the program then opens, you can double-click the file and have it open fine.

So, my mom is resigned to double-clicking a file, clicking cancel a few times, and then double-clicking the file again every time she wants to open something, until we find our Office 2000 disk.

I see the same thing with Visual C++ 6.0 in two circumstances: if the machine is busy so loading the workspace takes a long time, or if it asks me a question whilst loading (e.g. "save changes to previous workspace?").

Presumably this is a timeout kicking in somewhere -- if the handling application hasn't acknowledged (completion of?) the request within X seconds, presume there was a problem and return an error to Explorer.

I get a similar problem from time to time with VS 2005.  I'll check out a .cpp file from the command line, and then paste the path to that file into the command line and hit enter.  Most of the time, VS opens up and the file is displayed.  Every so often, VS will open up but no file is loaded (and there is no error message).  When I started reading this post I was hoping it would have an explanation.  Oh well, it's not that big of a hassle to just paste it to the command line again.

I thought DDE was deprecated when Windows 95 came along.

Speaking of double-clicking in Explorer - when I try to open a shortcut to a folder, sometimes Explorer navigates to it in the same window, sometimes it opens a new window. I can't find any logic behind it. Maybe DDE is at fault here?

I was baffled by the same problem, so many thanks for finding a fix. I haven't been near that DDE option so it must get switched on as a side-effect of something else.

I do have a vague memory of a prompt about inter-operating with other office apps

This happened to me as well. Since I was migrating to a new machine a week later I didn't bother too much. I never touched any Excel DDE options, and as I recall the whole thing started after Microsoft Update delivered patches.

I get it a lot - especially with large spreadsheets. In fact - it rarely (if ever) happens with small spreadsheets. And I don't have "ignore other apps" checked.

On a side note, the option is listed as "ignore other applications" in the options dialog - without a reference of DDE (only when diving into the help function you're told about that).

Just want to pipe in saying that I too see this alot around our office.  And in all cases the DDE options is not set. It's almost like the DDE system has crashed in the background(it hasn't and there isn't one) When this happens it's not just word or excel but acrobat or any other type of application that you launch through double clicking on files.  

What's up with all the MS apps using ddeexec to open associated files? What's so bad about simply taking it from the command line, calling FindWindow to find a previous application windows, WM_COPYDATA it the filename, then exiting?

Aha, this got me too! It started happening roughly around the time the Office service pack came down (that could be a coincidence of course)

I'm fairly certain I didn't click this myself. It's a mystery to me as to what enabled it.

Me Too(TM). I had this same problem and I'm fairly certain I didn't fiddle with that setting.

I get the same error in Word periodically, and have to change the explorer settings for the .doc file type.  It's a pain to remember what setting it is.  It's even more ridiculous that it needs to be done at all.

What bothers me more about this blog post is the tone of the "it's all explorer's fault".  No, it's MICROSOFT's fault.  They own Windows (and Explorer). They own Office.  They are supposed to work together. stop blaming each other!

I suppose I should clarify my "Me Too" post. When I installed Office 2007 on my 32-bit Vista machine everything worked fine, but somewhere along the way the exact problem you described in this post started happening, and I don't know how or why. I certainly don't recall ever changing the option you describe, since I would expect that to do just what you said it did. I never managed to fix the problem until I installed 64-bit Vista on the machine and subsequently re-installed Office.

I've seen similar behavior when an Excel add-in throws up a dialog box during Excel start-up.

This happens even if I dismiss the dialog bow right away.

However, there is no error message. I simply get Excel without any documents open.

> steve.thresher

> Any chance you could point me at a copy of ddespy so I can investigae further.

ddespy.exe is a part of Visual Studio V6.0, I have it installed into this folder:

C:\Program Files\Microsoft Visual Studio\COMMON\Tools\WinNT

I checked the computer of a developer at work who has all versions of visual studio .net, and ddespy.exe is not included in any of them.

As for the actual problem, I too have encountered it on many occasions.

Although it was years ago now since the last time I recall having seen it.

I remember it as one of the signs Windows will sometimes give you that it's time to save your work and reboot before something worse happens...

I also remember that a system service that should be running but no longer is, could possibly cause this, but I may be confusing this with some other problem, it's been a while.

This was in the Windows 2000 era.

I also have a recollection of some virus or malware causing this problem back in that timeframe.

You can reproduce the problem of not being able to open Office documents by double-clicking them, by killing the svchost that runs rpcss.

Windows wants to reboot if you do that, but you can abort that by running "shutdown -a" before the timer runs out.

Pcooper::  I recommend that you ALWAYS install all software by copying the whole CD to a folder on a local drive, then install the software from there.  That way, you'll always have the installation source available for just these kinds of issues.  (Assuming you have modern hard drives of 40 or 100 or 500 gigabytes or so.)

When software like Office comes preinstalled, I still copy the CD to a local folder as soon as I unpack the computer.  (The newer computers generally have done this for you.)

Adrian Oney:  Might be related to KB article 821136, which might mess with the DDE setting (it's not clear).

Wow, aren't you an arrogant asshole, just the kind Microsoft wants working for them (That's for this blog, but posting was disabled there: http://blogs.msdn.com/oldnewthing/archive/2008/04/14/8389268.aspx )

It IS an explorer (or shell API) bug.

Explorer mistakenly told the user "Windows cannot find 'FilePath\FileName', Make sure you typed the name correctly, and then try again."

Would it be so difficult to distinguish between "The executable doesn't exist", "The executable failed to run", "The executable ran but didn't accept the (DDE) open request", and "The document doesn't exist"?  The problem is the attitude of "our users are too stupid to understand the problem and fix it".  The reality is that you owe users an accurate error message, preferably in plain language not programmer-ese, so that the ones who do understand, and the IT-knowledgable friends of the ones who don't, have a head start actually resolving the problem.

Isn't that for MS to figure out? :) It would make it a better user experience no?

@Mike: They did figure it out, you just don't like the answer. Simply saying "It sucks and should be better" is not helpful.

Somebody else must have asked this, but here goes...

Why on earth is there an option for that in the first place? It seems like it was just begging for something like this, since there's no way this user is going to understand the connection between DDE and "my file doesn't open".

This happened on a few of our workstations some time ago on a wednesday morning. I remember using windbg, process explorer, filemon and regmon to troubleshoot the problem, to no avail. In the end I got angry and started exporting and importing office registry keys from a working office installation. That fixed it.

It might have been related to dde , although I do not believe 20 users simultaneously enabled this option.

Thank you, thank you, thank you. One of my computers has been doing this since shortly after Office 2007 came out, and I've been to hell and back with the associations.

I don't think I'd ever have changed that option (Excel options? Why!?) so perhaps some add-in did at some point (then again, I can't remember installing any add-ins either)...

Anyway, thank you once more.

@Lothar: If you can remember the date better, it may be due to one Office patch or another. Wednesday morning would be the day after Patch Tuesday. I'm guessing one patch flubbed the registry setting accidentally.

And it might make sense given the number of people having the same issue. Word may not have the option, but the registry version equivalent might just be the ticket.

I agree with Ben Voigt!

The real problem here is that Explorer is displying a misleading error message which leads to a very unpleasant user experience.

Raymond is probably right that there is no easy fix for this issue, I suppose the shell has valid reasons for using ShellExecute when the user double-clicks a file, and I suppose that ShellExecute has valid reasons for returning a misleading error code. This is probably hard to fix.

But, this does not mean that it is impossible to improve the situation. If this issue was given enough priority, I am sure that some smart Microsoft people could come up with a much better solution than what we have today.

The only real question is how important this issue is relative to everything else that needs fixing.

In my opinion this is very important. Double-clicking documents is the primary way users (especially naive users) open documents in windows. If the computer gives misleading error messages in this situation, the user will get angry and frustrated:

Computer: "Make sure you typed the name correctly, and then try again"

Angry user: stupid computer, I did not type the name at all - I double-clicked a file! Why do you try to blame me when it is your own fault. Stupid microsoft crap &%&%/&#¤

So, at the very least, explorer could display a different error message when double-clicking a file than when the user manually types a file.

It might even be possible to have ShellExecute collect some detailed diagnostics that a power user could display by clicking a link in the error message dialog.

Raymond, you say that "A misconfigured copy of Excel resulted in an error message that by all indications looked like an Explorer bug" - it IS an explorer bug! Resolving the issue by reconfiguring excel misses the point: The real problem is that the error message is misleading!

I face a similar problem with Powerpoint ppts. Whenever I double click on a ppt which has animations set, the slideshow starts and does not allow any user inputs. The slide show continues at a very slow pace.

Because of this constrain I have to manually open all ppts in Powerpoint

Any Help :-)

stefang: "The real problem here is that Explorer is displying a misleading error message which leads to a very unpleasant user experience."

I've seen Raymond discuss psychic debugging, but I still haven't seen him mention psychic software. How, exactly, was Explorer supposed to return an error message when it was Excel that was failing to recognize the command that the shell sent to it?

Quoting Raymond: "So far as the shell was concerned, it was sending the command that Excel registered as the 'Please send me this command when you want to open a document,' and yet when Explorer sent that very command, Excel responded with 'Huh? What are you talking about?'"

Why blame a bit of software for doing it's job? I get this sort of thing from clients of libraries for which I'm responsible, and some of my days are spent explaining why my software can't predict the future or patch other processes or guess what the client really intended to do when it called my API incorrectly. I'm beginning to develop the interpersonal skills of a thermonuclear device as a result.

PMP

PMP: Unless I am totally mistaken, Explorer is displaying the error message - not Excel.

* The user double-clicks a document in explorer

* explorer uses shellexecute to open the document in the associated program.

* This fails because excel is improperly configured.

* ShellExecute returns an error code meaning "File not found"

* Explorer displays a message to the user that he should make sure that he is typing the name correctly.

* The user gets pissed off because the offensive and clearly incorrect error message.

There is no need for any psychic software. Explorer knows that the user double-clicked a document. Explorer knows that the operation failed. Explorer can definitely display a better error message than it does today.

The only issue is if it is worth the time and effort to improve the error message in this situation.

I believe that it is extremely important to get these kinds of error messages right - blaming the user for a problem that is clearly not his fault creates a very bad impression.

Note that I am not talking about error codes returned from a library - I am talking about the plain english error message displayed to the end user.

I place the blame on ShellExecute().

I think SE_ERR_DDEFAIL (The DDE transaction failed.) would have been a much more helpful error code.

I'm certain I didn't select that option, and yet I had this same problem.  Thanks for the solution.

Why does a program from 2007 still use frickin oldskool DDE? That is like the "The Old Old Thing".

When you hear DDE was "deprecated", you need to remember DDE was more than just fancy window messages: DDE was the predecessor to OLE and COM. In *that* sense it's deprecated. But DDE for shell commands is just too convenient compared to the alternative (making your document type only accessible as an OLE document), not to mention all existing protocols based on DDE that will stay DDE - the Netscape DDE protocol, still supported by all major browsers; the Program Manager protocol for installers, still supported by the shell; etc.