Taming Microsoft Word 2007’s File Associations and Document Windows, Part One

Last weekend, Paul Thurrott, Bryant Zadegan, and I met up downtown (Washington D.C.) for dinner and ranted on various issues that drive even the expert Microsoft Windows users up the wall. Oh and we even talked about the iPhone, but that’s another story.

One of the gripes Paul had was with the z-order of his open windows being tampered with when opening two (or more) Microsoft Word documents. At first I thought of saying, what the hell are you talking about Paul, but resorted to the less abrasive: What?

Paul explained that if you open a Word document, minimize it, open an Excel spreadsheet, then finally open another document, both Word windows come to front, preventing you from ALT-Tab’ing to the spreadsheet you were working in. Come again, right?

Okay, here’s a video to make things a little easier to understand.

Get the latest Flash Player to see this player.

Given this appears to be an issue with the invocation of Word through a file type association (i.e. double-clicking), I jumped into HKEY_CLASSES_ROOT\Word.Document.12\shell\Open\command to check out the file association keys and parameters. The default value was set to:

C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE" /n /dde

As per KB210565, /n instructs Word to starts a new instance of itself with no document open (would normally be a blank page). /dde, sadly undocumented, instructs Word to fire up its “DDE server”. Seeing as there is no %1 argument here, you’re probably wondering how Word opens the document you double-clicked…

Back in the 16-bit computing era, an inter-process communication method called Dynamic Data Exchange (DDE) was created, with the purpose of allowing data to be shared between applications. Today, with the advent of technologies such as COM and OLE, DDE isn’t very useful, but you’ll still find it in use deep within the bowels of Windows. You can read more about DDE on MSDN, Wikipedia, and on Raymond Chen’s blog.

Alright, so to instruct the shell that it must speak old DDE tongue with Word, an additional key must be present: HKEY_CLASSES_ROOT\Word.Document.12\shell\Open\ddeexec. This key, and the values beneath, instruct the shell how to inform Word, via DDE, that the user is trying to open a document. You’ll notice the default value for this key has FileOpen(“%1”), an instruction that merely simulates clicking File –> Open.

In layman’s terms, here’s what happens in Paul’s case. Bear with me folks.

First document invocation:

1. Paul double-clicks a .docx file
2. The shell (Windows Explorer) checks the registry for information on dealing with the ‘open’ action, notices ddeexec key, and goes down the DDE speak route
3. The shell sends out a broadcast asking for someone to step forward and handle Word requests
4. A DDE server accepting Word requests doesn’t respond (as it’s not running), therefore the shell fires up a new instance of a DDE server using the command value (i.e. winword /n /dde)
5. The shell sends the FileOpen(%1) instruction to the new instance of Word.
6. Document opens.
7. Paul minimizes the document and opens other windows…

Second document invocation:

1. Paul double-clicks a .docx file
2. The shell (Windows Explorer) checks the registry for information on dealing with the ‘open’ action, notices ddeexec key, and goes down the DDE speak route
3. The shell sends out a broadcast asking for someone to step forward and handle Word requests
4. A DDE server accepting Word requests responds (Paul’s previous document).
5. The shell sends the FileOpen(%1) instruction to the existing instance of Word.
6. The existing instance of Word brings its window to front to handle the FileOpen instruction
7. Paul screams.

Make sense now?

In the second part, I’ll demonstrate how a simple kitchen butter knife can stop this behavior and how Paul asked for my hand in marriage…