Skip to content

DragAndDropContainer: Document support for dragging between windows - #1692

Open
owenpkent wants to merge 1 commit into
juce-framework:developfrom
owenpkent:docs/dragdrop-cross-window
Open

DragAndDropContainer: Document support for dragging between windows#1692
owenpkent wants to merge 1 commit into
juce-framework:developfrom
owenpkent:docs/dragdrop-cross-window

Conversation

@owenpkent

@owenpkent owenpkent commented Aug 2, 2026

Copy link
Copy Markdown

What

Adds a paragraph to the DragAndDropContainer class documentation noting that a drag can be dropped onto targets in the application's other windows, and pointing at the allowDraggingToOtherJuceWindows parameter of startDragging().

Documentation only. No functional change.

Why

The class comment currently describes a drag as being delivered to "any child components derived from DragAndDropTarget which the mouse moves over", which reads as though a drop is confined to the container's own window. Cross-window support does exist, but it is reachable only through the fourth positional parameter of startDragging(), it defaults to false, and it is documented solely in that parameter's own @param entry.

Someone reading the class documentation to find out whether JUCE can do this comes away believing it cannot.

As evidence that this is a real failure mode rather than a hypothetical one: I hand-rolled cross-window dragging across roughly 180 lines and five files in Keys, a VST3 plugin that drags chords from a detached window onto a pad strip in the main editor. I had concluded from this class comment that the framework did not support it. Three separate comments in that codebase state it as settled fact:

The drag crosses windows, and nothing in JUCE does that for free. [...] a DragAndDropContainer would never see the drop

no drag-and-drop container spans two desktop windows, so the source cannot find this component and this component never sees the mouse

The drag crosses two top-level windows, which JUCE gives nothing for: a DragAndDropContainer only ever sees a drop inside its own window

All three are wrong. The hand-rolled version locates its target with juce::Desktop::findComponentAt() followed by a walk up the parent chain, which is close to exactly what findDesktopComponentBelow() and findTarget() already do. Had the class comment mentioned the capability, none of it would have been written.

The implementation has supported this for a long time: startDragging() puts the drag image on the desktop when the flag is set, which makes getParentComponent() null in findTarget() and routes target lookup through findDesktopComponentBelow(), iterating every desktop component in z-order before walking up the parent chain for an interested DragAndDropTarget.

The added paragraph goes in the class comment so the capability is visible to someone deciding whether the class fits their problem, rather than only to someone who has already chosen it and is reading the parameter list.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant