Drag and drop wrong position bug with scaled plugin window

JUCE 6 (not the very latest tip). We have a scalable plugin and scale the child- component that contains all the UI with the following code according to the plugin size:

subComponent->setTransform(AffineTransform::scale(scale))

The position of the transparent default drag image has an offset when starting to drag the component when we make the plugin smaller or bigger where the scale factor is not 1:

image

Any help or fixes are welcome. Thanks.

Edit: It selects the right target. It is the semi-transparent drag image that is in the wrong position.

The image to mouse pointer offset is calculated without scaling in juce_DragAndDropContainer.cpp

        imageOffset = clipped; // <-- wrong offset to mouse pointer when scaled
    }
    else
    {
        if (imageOffsetFromMouse == nullptr)
....

Please can someone from the JUCE team have a look at this @ed95 ?

Steps to reproduce:

  1. Scale the component that contains the drag and drop source and target.
  2. Drag the component
    → the drag image is not at the right position when the component is scaled

The problem is that the juce_DragAndDropContainer.cpp in startDragging() mixes the mouse position (getLocalPoint()) with the unscaled component bounds. That ends up in the wrong calculation of the drag image position.

Let me know if you need some more information.

Hi kunz,

thank you for reporting this, I’ll take a quick look.

Thanks a lot.

The fix will probably be out tomorrow and might be different from this.

In any case, can you check please if this patch fixes your issue?

fix_drag_and_drop_affine.patch (1.2 KB)

Hi Attila

I have tested the patch and dragging with a scaled UI works as expected now. Thanks :slight_smile:

I just noticed that the fix didn’t make it into the JUCE 6.1 master. When can I expect to have this in the master branch?

The 6.1 release was already out before this fix, and then it was held back a bit to make sure we are not introducing regressions before 6.1.1 and 6.1.2.

The fix is now out on develop at commit 823bfb0 and will be part of the next release on the master branch.

2 Likes