reuk
January 13, 2025, 6:19pm
18
I think it’s unrelated. The change is designed to fix the assertion on releasing the mouse; if the drag is failing for some other reason, then this change won’t help.
This is the commit containing the fix:
committed 04:56PM - 13 Jan 25 UTC
Before this change, when starting a mouse drag from a nested view such
as a webv… iew, JUCE was unable to automatically determine which component
is associated with the drag.
Instead of relying on automatic detection, users can pass the
"sourceComponent" argument when initiating a drag to specify the parent
view that should receive associated drag events. However, previously the
sourceComponent was only used to find the view associated with the
mouse-down, but not the mouse-up. Automatic detection was always used
for the mouse-up, but this could fail in the case of a drag started from
a nested view.
Now, the drag event source will store a weak reference to the source
component provided by the user, and use the same component for both
mouse-down and mouse-up events.
Please try out the change and let us know if you’re still seeing problems.
