We have been using ddeexec registry entries to handle opening a design from Explorer.
MSDN (about 2/3 way into article) indicates that ddeexec is deprecated, and applications should use IDropTarget instead.
What is unclear to me is how that this actually is supposed to work..
e.g. If I have Foo.exe, which is intended to handle .foo files, what does the registry look like?
HKCR\.foo
(default) = Foo.foo.1
HKCR\Foo.foo.1
shell
open
command
(default) = ?????
If the command is set to the obvious:
"C:\Program Files\Foo Corp\Foo.exe" "%1"
then Foo.exe is launched each time the user double clicks on, or chooses open from the context menu for a .foo file.
However, that means a separate instance of Foo.exe is launched for every file that the user attempts to launch. YUCK.
I can certainly write custom code to somehow pass on the filename from the 2nd instance of Foo.exe back to the first instance of Foo.exe and then exit... but then I'm writing a fair bit of custom code.
DDE used to handle this gracefully (enough) by asking the already running first instance of Foo.exe to open the specified file. This made it easy to have an MDI app skillfully handle opening multiple documents, where each one was opened within the one instance of Foo.exe.
If DDE is deprecated, then what is the preferred mechanism? Our app makes much more sense as an MDI app - we certainly don't want several instances of Foo.exe running (that would only annoy our users). I certainly don't want to have to write a new Foo-Shim.exe which looks for the real instance of Foo.exe, and uses some custom mechanism to pass the filename being opened to it. (I can't just use Foo.exe for this purpose, because Foo.exe is big, and slow to load, and requires an activation security code which is counted per instance, and so may refuse to start up if you're at your maximum concurrent user limit).
I don't see anything in IDropTarget which looks like it has much of anything to do with this (common) scenario.
Does anyone know what MS intended here?