|
|
I can try, but it isn't going to be easy...
Is there a MWE of drag-n-drop that I could start from -- it is probably easier to start there and extend a Fl_Button to be the origin of the payload rather than start from my program and strip it down.... (hopefully it would show the same odd behavior).
My program uses a bunch of classes that hold Fl_Widgets -- duplicating all that in a MWE is not going to be small or clear...
I'm generally confident in what we're doing -- it has worked fine for about a decade.
In the short term, if you have the time and desire to dig deeper, I'll try to present a guide through the real code with the parts I omitted the first time filled in....
1 The over-ridden Fl_Button::handle is implemented here as VspButton. 2 The wrapper class that contains the over-ridden Fl_Button is defined here, it is ParmButton. 3 That wrapper is an extension of a base wrapper class defined here, it is a GuiDevice. 4 When the wrapper is set up, the Fl_Button::callback() method is called here in ParmButton::Init(). Which references GuiDevice::StaticDeviceCB, which always turns around and calls the class's DeviceCB. 5 The ParmButton's DeviceCB is the other bit that implements the callback here.
This is how I handle 'low-level' events. These are typically fairly universal behavior throughout the program.
My original email summarized only steps 1 & 5. Hopefully 2-4 help answer your question.
A bunch of GuiDevices are typically associated with a Screen. That screen is where the developer usually does most of their GUI work including a callback for the entire screen. This is where unique behavior of individual buttons is implemented.
Higher level events are passed to m_Screen->GuiDeviceCallBack() as the last line of the ParmButton::DeviceCB.
Rob
On Monday, May 24, 2021 at 2:26:11 PM UTC-7 Ian MacArthur wrote:
On 24 May 2021, at 19:47, Rob McDonald wrote:
>
> I have an extension of Fl_Button to support drag-n-drop. I do this...
>
> int MyButton::handle(int event)
> {
> int ret = Fl_Button::handle(event);
> switch ( event ) {
> case FL_DRAG:
> if( callback() )
> {
> do_callback();
> }
> ret = 1;
> break;
>
> default:
> break;
> }
> return ret;
> }
>
> 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...
>
> void ButtonHolder::DeviceCB( Fl_Widget* w )
> {
> if ( w == m_Button ) // m_Button is the pointer to the MyButton
> {
> switch ( Fl::event() ) {
> case FL_DRAG:
> Fl::copy( m_Foo.c_str(), m_Foo.size(), 0 );
> Fl::dnd();
>
> break;
>
> case FL_RELEASE:
> if( Fl::event_inside( w ) )
> {
> // Do something else.
> }
>
> break;
>
> default:
> break;
> }
> }
> }
>
> The problem is -- every time a FL_DRAG event is started, the FL_RELEASE event immediately triggers (even before a button release). This only happens on MacOS, it does not happen on Windows. This code worked fine on 1.3.X.
>
> Any ideas why Clicking and holding (drag hasn't even started) on MacOS would trigger a Release event?
Can you put together a minimal (complete) example that shows the behaviour?
I’m having trouble putting it all together in my head...
Like... when exactly does DeviceCB() get called, and why does it call Fl::event() rather than, say, being passed the current event of interest? In particular I’m concerned that what Fl::event() is returning here might not actually be the event of interest, if it is being called in the wrong context, say...
Or something else.
--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/a69d657a-80c5-48df-aca2-ed05a86f3bedn%40googlegroups.com.
[ Direct Link to Message ] | |
|
| |