2

In some badly-implemented software (in my case, iPhoneBrowser and MP3Gain, but there are others) after dragging a file/folder from explorer into the program, the explorer window will become unusable until the program finishes its operation. It cannot be resized, moved, or minimized, and none of the buttons or icons can be interacted with (the cursor is stuck on the "drop here" cursor). This lasts until the program finishes its operation It is possible to open another explorer window and navigate back there, but the original window is still frozen.

To be clear, this occurs with third-party software that responds to the drag-and-drop in the thread that created the event. Copying files in explorer does not trigger the issue.

Is there a way to prevent this behavior, so I can still interact with the explorer window while the program does its thing in its own thread/process/whatever? I have Windows 7 x64, but the behavior was present in XP32 as well, IIRC.

Improve this question
3
  • 2
    Don't use poorly-written software that doesn't handle drag/drop well? I think you've already identified the real problem. Any answer will be a workaround at best.
    – Velociraptors
    Aug 26, 2010 at 0:58
  • Sadly, iPhoneBrowser is the best program that can do what it does. It's open-source and .NET, so I might just fix it myself.
    – Robert Fraser
    Aug 26, 2010 at 1:46
  • 1
    And the problem is in Windows. Sure, the software could be better, but one fix to explorer could fix hundreds of buggy programs.
    – Robert Fraser
    Aug 26, 2010 at 1:48

5 Answers 5

Reset to default
1
+100

It IS fixable*, but you'll have to change your workflow slightly.

What you need is a helper application that implements both sides of drag-and-drop. When files are dropped to this helper, its IDropTarget will make a copy of the drop list and then free explorer to doing other things. Then you will drag-and-drop from the helper to iPhoneBrowser, which will lock only the copy of the drop list and not the original used by explorer.

By multi-threading the helper, it should also be possible to avoid having it frozen for the duration.

*Some assembly required. If you're not a programmer, make friends with one

Improve this answer
1
  • Awesome; just what I was looking for. If I'm really bored someday, I'll make this.
    – Robert Fraser
    Sep 1, 2010 at 16:57
3

I have written programs that handled drag and drop of files, and can say that this situation will only exist for badly written file-drop handling programs.

The lazy programmers kept the drop list open while processing the files, thus freezing Explorer, instead of just first getting out of it all dropped file names and then closing the list, so as to free Explorer BEFORE doing the processing.

Improve this answer
1
  • Ah, the post wasn't very clear. The freeze lasts until the program finishes its operation, and does not occur when copying files. I think the problem is that Windows gives control of the thread to the application that finishes its task on that thread.
    – Robert Fraser
    Aug 26, 2010 at 13:36
2

I´m not sure, if I understand your problem correctly but have you considered opening a second explorer window?

Improve this answer
2
  • Yes, this works, but I have to navigate back to where I was.
    – Robert Fraser
    Aug 24, 2010 at 18:48
  • 1
    FYI, you can right-click (or shift+click) folders and the like from one explorer instance to create another, new, instance pointing at that location - which will save some navigation.
    – DMA57361
    Aug 25, 2010 at 11:59
1

What about an application that takes over the entire copying process? e.g., SuperCopier 2

Improve this answer
0

It may seem like a strange answer, but for large copying operations I tend to use xcopy. Yes, which I first learned how to use with DOS 6. It still works.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .