Discussion:
Suggestions on how to get Target Folder after DoDragDrop has finished...
(too old to reply)
Siegi
2007-08-04 03:49:25 UTC
Permalink
Hi!

what i'm actually trying to accomplish:

I'm writing a plugin that needs to hook into drag&drop operations (files).
i'm using import/export table modificaton hooks. On RegisterDragDrop i
provide my own IDropTarget class (it usually just passes everything through
to original class). Everythings fine regarding drag&drop (usually explorer)
to calling application.

The other way round seems to be much harder. I've got a hook into DoDragDrop
and i'd really like to avoid again mimicking both IDataObject and
IDropSource (what would be a dragged file from calling application can also
result in a folder containing several files), but just wait for DoDragDrop
to finish and process/change file afterwards.

Querying IDataObject for CF_FILEGROUPDESCRIPTOR gets me all filenames. What
i'm missing is the information where the file has been saved to.

I'm not allowed to provide a shell extension, although that seems to be the
only proper approach anyway^^

I've been thinking about using a global hook, checking there for
explorer.exe (i've not seen drag&drop working in any other process so far,
application is only providing CF_FILECONTENTS & CF_FILEGROUPDESCRIPTOR) and
wait for left or right mouse button to be released and store hwnd. Maybe
only read this information within one of the calls to IDataObject since it's
within DoDragDrop and might be more accurate?

I've seen some approaches that might get filepath from hwnd (e.g.
http://blogs.msdn.com/oldnewthing/archive/2004/07/20/188696.aspx).

Does anyone has a suggestion on how to get this information?

It's no big deal if this approach would fail from time to time...

Thanks,
Siegi
James Finnigan [MSFT]
2007-09-02 07:57:08 UTC
Permalink
I'm no dragdrop expert, but you definitely need to remember the open file
dialog. I drag into and out of that all the time, and it can be in any
process.

(Also, I have to say what you're describing sounds really scary, probably
breaks the rules of COM for QueryInterface, and could lead to system
instability. If you share more details about what you're trying to
accomplish perhaps folks can help you find a better way.)

HTH,
--
James Finnigan [MSFT] ( http://blogs.msdn.com/jamesfi )
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm.
Post by Siegi
Hi!
I'm writing a plugin that needs to hook into drag&drop operations (files).
i'm using import/export table modificaton hooks. On RegisterDragDrop i
provide my own IDropTarget class (it usually just passes everything
through to original class). Everythings fine regarding drag&drop (usually
explorer) to calling application.
The other way round seems to be much harder. I've got a hook into
DoDragDrop and i'd really like to avoid again mimicking both IDataObject
and IDropSource (what would be a dragged file from calling application can
also result in a folder containing several files), but just wait for
DoDragDrop to finish and process/change file afterwards.
Querying IDataObject for CF_FILEGROUPDESCRIPTOR gets me all filenames.
What i'm missing is the information where the file has been saved to.
I'm not allowed to provide a shell extension, although that seems to be
the only proper approach anyway^^
I've been thinking about using a global hook, checking there for
explorer.exe (i've not seen drag&drop working in any other process so far,
application is only providing CF_FILECONTENTS & CF_FILEGROUPDESCRIPTOR)
and wait for left or right mouse button to be released and store hwnd.
Maybe only read this information within one of the calls to IDataObject
since it's within DoDragDrop and might be more accurate?
I've seen some approaches that might get filepath from hwnd (e.g.
http://blogs.msdn.com/oldnewthing/archive/2004/07/20/188696.aspx).
Does anyone has a suggestion on how to get this information?
It's no big deal if this approach would fail from time to time...
Thanks,
Siegi
Loading...