| |
| |
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 ] | |
|
| |
