2
votes

What I'm trying to do is to display a listview of online files, just like an FTP client lists all the files on the FTP server, and one can drag any row or rows to any local folder to save the dragged files right there.

I'm planning to implement this through the follwing steps:

  1. init the drag event, and save the selected files' path on the server [done]
  2. subclass QMimeData class, and overwrite retrieveData function just as this thread suggests here [done]
  3. Just finish the drag and drop process, and find the dropped destination path, say C:\somefolder\subfolder, then download all the files there, job done. 【not done】

But I could not find anywhere to get the dropped destionation path, not even by processing dragEnter\dragMove\dragLeave\drop events. I've also done tons of google search, found some similar questions but never any solid answer.

Please shed some light on this. Is this solutuion even doable with QT ? How should I get the destination path or is there any other way to achieve this goal ?

1
Windows doesn't provide any way to discover the target of the drop. It does provide a way to perform asynchronous data transfer. I'm pretty sure you can't pull that off with Qt alone, you'd have to use Windows API directly.Igor Tandetnik
@IgorTandetnik thanks for the reply, I believe IAsyncOperation may be able to achieve what I want, but I choose another way. I just give the drag event some files that do not exist as the url list so the drag can SEEM TO BE HAPPENING. and when dropped, of course, nothing will happen cuz the file url list is fake. I just find the window HWND at the drop position, and try to find it's path [forums.codeguru.com/… ], and just download my files there. This is stupid of course, but to me it's easier to implement....Sean
What happens if I drop on a folder icon (so the folder the files should go into is not the same folder as the open Explorer window)? Or on a printer icon (in which case, I imagine, Explorer would want to drop to a temp directory first)?Igor Tandetnik
@IgorTandetnik hmmmmm, excellent question, haven't thought about that. Then I'll stick to IAsyncOperation! Thanks man. Please post your comment as an answer so I can mark it. And I'll come back with my outcome if I got any.Sean
@IgorTandetnik actually, I read about it, and I don't think it's the answer. In an async scenario, the [Drop Target] decides when to StartOperation and EndOperation, the [Drop Source], my app, does not get to control the whole process. the only benefit it brings is to unblock the source and target, this does not quit fit my scenario which is: the [Drop Source], my app, when dropped, will first download the dragged files form a web server which may take hours, and then I tell the [Drop Target], it's OK to copy the files now, before that, the [Drop Target] should just wait in the background.Sean

1 Answers

1
votes

For anyone who's searching for this, I might find an answer, but it ain't easy and could be platform dependent.

After tons of (literally) search, I found a solution in FileZilla's source code, turns out to cope with such situatuation, you need:

  1. you need a shell extension to monitor (or whatever) the drag process
  2. start a normal drag and drop
  3. when mouse is dropped, just do nothing, let the whole drag and drop process finish
  4. through the shell extension, you can get the actual destination path, and just download your files there.

for technical details, plz visit FileZilla official website

I think this is for windows only, if anyone get the answer for other platforms, please let me know!