So the Fl_Button do_callback() is wired up to capture FL_DRAG. The callback gets passed along to my class that contains the pointer to the MyButton... We'll call that a ButtonHolder. It handles the event with this code...
On 5/24/21 3:02 PM, Rob McDonald wrote:
I can try, but it isn't going to be easy...
Is there a MWE (*) of drag-n-drop that I could start from [..]
In 1.4.x there's examples/howto-drag-and-drop.cxx
I see that the macOS version of the D-n-D code sends an FL_RELEASE event right after the initial FL_DRAG event,
while the Windows versions sends it after the end of the D-n-D operation. ... Some more analysis is required to determine whether this FL_RELEASE event is wrong or not.
The user has released the mouse button dropping data into the widget.
(end of citation)
The docs don't explicitly state that an FL_RELEASE event is also sent, but I think this is necessary for apps not watching FL_DND_* events.
I confirm that, at least in my hands on macOS 11.3, FLTK 1.3 and 1.4 behave identically when dragging.
That's expected, I believe, because the underlying source code is identical in the 2 branches.
I'll check again (later today) and post again. (Not on the Mac just now...)
That may also explain why Rob sees this effect; I'd guess he is using an older "stable" version of 1.3.x for the bulk of his work?Rob, can you give 1.3.6 a try to see if it also "fails" for you or not?
Bad versions:1.3.6 Release appears to behave the same as 1.4.x0c70362e63d6 behaves the same as 1.4.x (I was actually on this version and hadn't noticed the problem).Good versions:1.3.5 Release behaves as I expect and desire.1.3.4-2 Builds, but graphics do not display on this new of MacOS1.3.3 Will not build cleanly with this new of OS / compiler1.3.2 Will not build cleanly with this new of OS / compiler - Version used when DND feature was introduced to my application
Bad versions:
1.3.6 Release appears to behave the same as 1.4.x
Good versions:1.3.5 Release behaves as I expect and desire.
Since there really aren't very many changes between 1.3.5 and 1.3.6, I did a little manual bisecting to see if I could help narrow the search.
The regression was introduced in:
46235ff92216 Transfer to branch 1.3 all changes in Fl_cocoa.mm from branch 1.4 as of 20 may 2020
It might be possible to do a better job bisecting this on the 1.4 branch -- where the changes were most likely implemented in a more fine grained way.
I tested the following:
47ba6632b1be -- Tip of master
371eb6565494 -- Tip of branch-1.3
Both worked great!
Thanks Manolo, Albrecht, & Greg.