Monday, May 26, 2008

A little more on Windows Drag and Drop

A few days ago I complained about the silly drag and drop behavior of several ZIP tools, my favorite 7-Zip included. My post contained a remark that this is actually a Windows problem, but I did not have any further information on it other than a few links to the 7-Zip forum where people talked about this.

Thanks to an anonymous commenter on the earlier post I can now point to a good source of more information: The also fabulous WinSCP tool comes with a special drag and drop extension that works around the limitation of first unpacking to a temp file and then copying to the final destination, making unzip operations very slow. From the documentation page at you can learn this:

Here is short explanation: Windows drag&drop mechanics does not allow source application of drag&drop operation to find out easily, where the files are dropped. It is up to target application (Windows Explorer usually) to transfer files to destination. It is rather reasonable, because source application can hardly transfer files to all possible destinations. [...]

To allow direct drag&drop downloads, the shell extension was developed. It misuses Windows Explorer CopyHook’s. CopyHook is COM object (DLL library) that is called by Windows Explorer whenever directory (not file) is transferred within file system. When you drag anything from WinSCP, it creates empty dummy folder in temporary directory and pretends that you as user drag that directory. Once your drop it to Windows Explorer, it calls the CopyHook’s (including the WinSCP shell extension), telling it what and where was dragged. This way WinSCP knows the actual destination. It cancels the drag&drop operation, so the dummy directory is not copied by Windows Explorer and transfers your actual selection to now-known destination.

Go read the whole text in case you'd like to know the full story. Unfortunately the link to the MSDN library seems dead, so here is a (currently working) replacement:

BTW, why do they keep changing their URLs all the time? Even most private blogs jump through hoops to keep their permalinks valid when they change the site, why can't MS?

This is definitely a reason for me to use the installer package in the future instead of the standalone executable download I used to grab.

1 comment:

Anonymous said...

Hi Daniel!

Klasse Beitrag, vielen Dank daf├╝r!

Aber, muss man *unbedingt* eine DLL schreiben? Kann man den CopyHook nicht direkt in ein kleines Programm mit einpacken ohne DLL?