Cannot create a ListBox subclass that is the DragAndDropContainer of itself

Development
1

In order to enable the drag and drop feature, ListBox instances expect to be inside a parent that is also a DragAndDropContainer:

void ListBox::startDragAndDrop (const MouseEvent& e, const SparseSet<int>& rowsToDrag, const var& dragDescription, bool allowDraggingToOtherWindows)
{
    if (auto* dragContainer = DragAndDropContainer::findParentDragContainerFor (this))
    {
        int x, y;
        auto dragImage = createSnapshotOfRows (rowsToDrag, x, y);

        auto p = Point<int> (x, y) - e.getEventRelativeTo (this).position.toInt();
        dragContainer->startDragging (dragDescription, this, dragImage, allowDraggingToOtherWindows, &p, &e.source);
    }
    else
    {
        // to be able to do a drag-and-drop operation, the listbox needs to
        // be inside a component which is also a DragAndDropContainer.
        jassertfalse;
    }
}

ListBox is also a class that’s meant to be inherited from, and I’d like my derived list box implementation to be the DragAndDropContainer of itself, rather than having to wrap it inside a parent component with the sole purpose of giving it a DragAndDropContainer to use.

Would it be possible to add opt-in support for searching the DragAndDropContainer from the ListBox instance itself, rather than starting from its parent?

Possible implementation:

add a searchDnDContainerFromThis member varialbe in ListBox, with appropriate setter and getter methods, and pass it to DragAndDropContainer::findParentDragContainerFor() as a new (default false) parameter that indicates whether the seach must begin from this or from its parent.

2

Even better, why not add the possibility to specify to the ListBox an DragAndDropContainer to use, in the form of a raw (non-owning) pointer?

This would allow to also delegate the drag and drop handling to some other Component, which is another desiderable feature I’m looking for.

If not specified with an explicit call to a setter method, the current algorithm remains as a fallback, which guarantees that no existing code is broken.

3

7 months later, I’m writing new code, I hit this issue again, I did forget about this topic I opened and I was going to open a new one with this same exact request.

Thank you past me for having already openend this
Any word from the JUCE team?