Site navigation

How to cancel drag-and-drop with ESC key?

General JUCE discussion
#1

Apologies if this is obvious but I couldn't find it anywhere.  How can I allow the user to press ESC to cancel a drag-and-drop operation (with DragAndDropContainer and DragAndDropTarget)?

#2

Coincidentally, I just hit this same requirement for tracktion, so will figure something out v. soon!

#3

Is there a way to achieve this behavior currently?

#4

It works already doesn’t it?
The only time I’ve not seen it work is with the standalone target for a plugin, where you need to have the file over the app window for Escape to work (on macOS 10.12 at least).

#5

Not sure about the file drag and drop, but we’re using DragAndDropContainer and DragAndDropTarget for re-ordering UI items and there’s no way to cancel a drag once you start it (without just dropping the item back in the same location or off to the side)

1 Like
#6

Could you listen for an esc keypress and use that to toggle what the result of isInterestedInDragSource would be?

#7

I havre the same problem. Using the Escape key to cancel a drag needs to be implemented as part of the framework. It is default behaviour that just must be there. Imaging you start a drag accidentally and all areas you could drop it at have a meaning and perform an an operation.

#8

I have the same problem. Using the Escape key to cancel a drag needs to be implemented as part of the framework. It is default behaviour that just must be there. Imaging you start a drag accidentally and all areas you could drop it at have a meaning and perform an an operation.

4 Likes
#9

There is one tricky workaround to cancel a drag when using DragAndDropContainer and DragAndDropTarget: generate a mouse up event programatically when some key is pressed (for example Esc). On Windows there is SendInput function (I did not implement this workaround on Mac but should be something similar). You have also to inform your components to ignore itemDropped otherwise this fake mouse up event will cause a regular drop.

#include <windows.h>
#include <iostream>

void simMouseLeftUp()
{
	INPUT Input = { 0 };
	Input.type = INPUT_MOUSE;
	Input.mi.dwFlags = MOUSEEVENTF_LEFTUP;
	SendInput(1, &Input, sizeof(INPUT));
};
#10

That’s why it needs to be handled internally. The OS does it this way.

1 Like
#11

Has this been implemented yet?

I’m on JUCE 5.4.4 and it seems that drag operations cannot be aborted with ESC.

If adding that appears to be too much of a breaking change, at least allow it as an opt-in solution when creating the DragAndDropTarget and/or when initiating the drag gesture with startDragging()

#12

Answering my own question: no, it has not been implemented even in the most recent version of JUCE.

To check that I have switched to the current develop tip and fired the JUCE DemoRunner.
The WidgetsDemo has a “Drag and Drop” tab with a ListBox that shows the same exact issue: any drag operation initiated on it cannot be aborted with the ESC key.

BUT

Looking at the code in juce_DragAndDropContainer.cpp, there is in fact this code already in place:

bool keyPressed (const KeyPress& key) override
{
    if (key == KeyPress::escapeKey)
    {
        dismissWithAnimation (true);
        deleteSelf();
        return true;
    }

    return false;
}

So it seems that at a certain point in time, the ESC key was actually supposed to do its job.
I’ll keep investigating…

#13

Ok, first issue I see is that the DragImageComponent that should handle the keyPressed(), returns false from its getWantsKeyboardFocus() method.

So, in its constructor I added:

    setInterceptsMouseClicks (false, false);
    setAlwaysOnTop (true);
    setWantsKeyboardFocus (true);    // < This
}

Then, just to make sure that the component has keyboard focus while being dragged, I’ve added the following to timerCallback()

void timerCallback() override
{
    if (isShowing() && ! hasKeyboardFocus (false))
        grabKeyboardFocus ();

It may seem overkill to repeat it over and over, but for now it’ll do.

Surprisingly, this still doesn’t solve the issue and the keystroke still isn’t triggering keyPressed() at all.

To understand why, I added an assertion right after grabbing the focus, to check whether the component actually got the focus as intended:

void timerCallback() override
{
    if (isShowing() && ! hasKeyboardFocus (false))
    {
        grabKeyboardFocus ();
        jassert (hasKeyboardFocus (false)); // < triggered if focus is not obtained for some reason
    }

Launched the demo again and the assertion is hit as soon as I start the drag operation. There’s something preventing the DragImageComponent from retaining the focus that it is trying to grab.

When ListBox starts a drag operation, it does so by allowing the drag to extend beyond the boundaries of the DragAndDropContainer, for dropping on an external target.
That behavior is controlled by the last argument of startDragAndDrop() (juce_ListBox.cpp, line 128),

owner.startDragAndDrop (e, rowsToDrag, dragDescription, true);

When it is true, the DragImageComponent is added to the desktop to allow being dragged externally.
I suspect that addition to the desktop causes some issue with focus, so I temporarly change that to:

owner.startDragAndDrop (e, rowsToDrag, dragDescription, false);

And in those conditions the ESC key finally does its job.

Now I wonder if all my previous changes to DragImageComponent were unnecessary, but it turns out that if I revert them, the ESC key stops working again, so they are also required after all.

Unfortunately, the ListBox code cannot be patched as I did, because it has its own very valid reason to allow external drops.

I hope some ComponentPeer magic can be done to allow DragImageComponent to retain its focus even when it is a desktop component.

I’m on macOS (Catalina) and I’m not fluent enough it its native programming to have an idea about that.

2 Likes