Erratic incomming DnD behavior

Windows
1

Hi Jules,

Since I’ve updated to the tip some time ago, I’m seeing weird behavior with DnD not always detected.
Depending on how fast I enter the DnD in my Window, it is either seen or not.

When it doesn’t work the first handleFileDragMove (from a JuceDropTarget::DragEnter) do not find any component as the x is equal -2 after that I never received any JuceDropTarget::DragOver.

You can easily reproduce it using Juce Demo and the code editor demo trying to DnD a file on the combo like file selector

Thanks,

2

Happen on Window 7 as well. Edited post title

3

If the only x coord that windows sends is -2, then doesn’t it seem reasonable that it wouldn’t find a target…?

4

I agree but it do not receive any new callback after that and it use to work in previous build.

Just try to the juce demo and the code editor demo trying to DnD a file on the combo like file selector

Incoming DnD on Windows is quite broken right now

5

By the way, it works like one time on six so please try another time if this works for you directly.

Thanks,

6

Ah, I see. It seems that in the JuceDropTarget::DragEnter class, it should always return S_OK, otherwise Windows gives up and doesn’t bother asking again. Thanks!

7

That did the trick.
You indeed need to returns S_OK to all the function of IDropTarget

Thanks,

8

No - AFAICT only DragEnter() needs to do that. The others can return S_FALSE if the drag event isn’t wanted.

9

You’re sure ?

http://msdn.microsoft.com/en-us/library/ms687242%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms680129%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms680110%28v=vs.85%29.aspx

10

Well… it does work correctly even when it returns S_FALSE, but I guess that according to the docs you’re right, it should be S_OK.