Curious that the 1.3.x code reads wrong, but seemed to work properly -- while the 1.4.x code is behaving in a way that matches the code. There must be some other code in some other region that is changing the observed behavior.
What is the difference in what initiates an FL_DRAG vs. FL_PUSH event? For example, what will happen if a user clicks and releases the button -- without ever moving the mouse a single pixel while the button is pressed.
In my mind, that should trigger a FL_PUSH, but not a FL_DRAG event. So, the way I read your suggested fix, it should fail for a push-but-not-drag event.
In practice, I can get your version to behave in three ways...
Quick press-and-release of button without movement -- fl_choice() window does not get displayed (broken)
Quick press-and-release of button with imperceptible movement (mouse icon does not change to truck) -- fl_choice() window is displayed
Press-drag-and-release of button (staying within button bounds), mouse icon changes to truck, - fl_choice() window does not get displayed (broken)
Rob
On Tuesday, May 25, 2021 at 1:32:16 AM UTC-7 Manolo wrote:
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. That part of the code is unchanged
between 1.3 and 1.4. Some more analysis is required to determine whether this FL_RELEASE event is wrong
or not. In the meantime, I suggest you modify a bit your handle() function as in the attached code to have it process
the FL_RELEASE event only after the end of a D-n-D operation. With this change, the test program is correct
Comments are owned by the poster. All other content is copyright 1998-2025 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.
