Possible drag drop bug on scaled windows


Is it possible that there is a bug in the FileDragAndDropTarget or related code on scaled windows systems?
I have now a test system with Win 10 and a 5K monitor so windows “UI-scale” is set to 200%.
When I drag a file on to my juce app (or the Juce Demo) the coordinates interpreted by Juce seems to be off.
So the position of the mouse and where the app “thinks” you drag don’t match.
Can anyone else confirm this?
Probably fine on OSX with all the retina systems, but it should be a matter of scaling up windows and drag a file to confirm this bug.



Yes, it’s entirely possible that there could be an edge-case there!

If you can provide some code to reproduce it, we can take a look…



Yes, this is an edge-case, but I would guess the user base is growing.
It can be reproduced by dragging files to a TreeView, for instance the ValueTree / XML demo in the Juce Demo.
Notice that the cursor changes to allow a drag operation, and that the scrolling of the TreeView changes when you drag up down. But it reacts when the mouse cursor is in the wrong place.
Guessing this is easy to fix if you know where in the code to multiply with GlobalScaleFactor :slight_smile:



Is this something you will be looking in to in foresable future, or should we put some effort in to it our self?
I get that there are plenty of more important issues at hand



Will try to take a look next week, but any clues you can give will help speed us up…



To give a starting point, I think it may be related to this topic:

I experienced this on windows with a scaling factor of 125%. To be honest, I didn’t investigate any further because it is not the most important issue for me, but if multiple developers run into this problem, it may be worth fixing…



Ok, I “fixed” this by altering this section starting on line 1041 of juce_win32_Windowing.cpp

 struct OwnerInfo
            OwnerInfo (HWNDComponentPeer& p) : owner (p) {}

            Point<float> getMousePos (const POINTL& mousePos) const
				Point<float> result = owner.globalToLocal(Point<float>(static_cast<float> (mousePos.x),
                                                          static_cast<float> (mousePos.y)));

				float scale = Desktop::getInstance().getGlobalScaleFactor(); //Get scale of desktop
				result.setXY(result.getX() / scale, result.getY() / scale); //Divide it to get "Juce-pixels" from native pixels

				return result;

It is possible that this division should be applied as early as in the “globalToLocal” function, but I don’t know if that would break something (?)



Thanks for the heads-up, I’ve pushed a fix to the develop branch - let me know if it still misbehaves…



Tested the fix today:
Still no success, needs a small change:

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

Moved the owner.globalToLocal function to before the unscaledScreenPosToScaled, don’t ask me why.



Bump. Found same issue here on Windows 10, when system scale is not 100%. The file mouse drop region is also kind of “scaled”. Using juce 4.2.4.



Had the same problem. If it helps anyone; I fixed/patched this by changing

ownerInfo->dragInfo.position = ownerInfo->getMousePos(mousePos).roundToInt();


const float scale = 1.f / Desktop::getInstance().getGlobalScaleFactor();
ownerInfo->dragInfo.position = ownerInfo->getMousePos(mousePos).transformedBy(AffineTransform::scale(scale)).roundToInt();

in both these functions in juce_gui_basics\native\juce_win32_Windowing.cpp

JUCE_COMRESULT DragOver (DWORD /*grfKeyState*/, POINTL mousePos, DWORD* pdwEffect)
JUCE_COMRESULT Drop (IDataObject* pDataObject, DWORD /*grfKeyState*/, POINTL mousePos, DWORD* pdwEffect)
1 Like


Is this fixed in the latest JUCE 5? I’ve just spent two hours working with a JUCE v4 project to discover i’ve got a negative coordinate when dragging files from the file system to the UI on a 4k monitor.



I mean, it doesn’t look fixed :slight_smile:



Ah - ok - maybe it is. Found the relevant line … it’s all changed a bit dramatically there actually.