Reversed component hierarchy for FileDragAndDropTarget on Windows


When I set up a component hierarchy on MacOSX with a top-level component that accepts FileDragAndDropTarget, any of the child components delegate to the top-level one. However, on Windows it's the other way around, any child component, even one that isn't extending FileDragAndDropTarget, seems to override the top-level drag target.

Has anyone dealt with this? I suspect this isn't normal? Anything I can do to fix this?



Actually that's not what's happening. It seems to be related to the Windows text DPI size when it's higher than 100%. It seems the Drag & Drop target screen coordinates are not taking the the different resolution, meaning that the drop target is wrong and not hitting the right components or location.

Thanks - I'm still tinkering with the high-DPI windows code and there are probably still a few edge-cases. I'll do some testing of drag-and-drop...

I just ran into this same issue, and it still exists in the latest release.  The issue only happens with file dragging (not dragging components within the app).  The problem is that the coordinates passed by the OS do not appear to be scaled.  This is easy to repro in the JUCE demo with the drag and drop widget example.  Just set your Display scaling to something greater than 100%, and drag a file into the taget rectangle in the demo.  It will only accept the drag if you drag into where the target rect *would* be if the scaling was at 100% (above and to the left of the actual target rect).

If you don't have a high DPI display, you can also simulate this w/o changing the overall system scaling by manually tweaking the JUCE native Win function getGlobalDPI() to return a hardcoded value (for example 120.0 for 125% scaling).  That function lives here:


The fix is to change HWNDComponentPeer::JuceDropTarget::OwnerInfo::getMousePos() to scale the coordinates, like so:

Point<float> getMousePos (const POINTL& mousePos) const

    return ScalingHelpers::unscaledScreenPosToScaled (
        owner.globalToLocal (Point<float> (static_cast<float> (mousePos.x), static_cast<float> (mousePos.y))));



Hi jimw, thank you for your bug report. We are aware of this problem along with a few other issues related to windows scaling. See this post for a more detailed explanation.

Thanks.  I had seen that other post, but it didn't seem to me like it applied to this particular issue.  In this case, the OS is not sending scaled coordinates to the drag handlers, so the fix above just scales the coords so it works properly with the rest of the JUCE code.