STR #2978

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]

STR #2978

Application:FLTK Library
Status:1 - Closed w/Resolution
Priority:2 - Low, e.g. a documentation error or undocumented side-effect
Scope:3 - Applies to all machines and operating systems
Subsystem:Core Library
Summary:FL_DND_LEAVE not passed to handle() function
Version:1.3.2
Created By:jlp2
Assigned To:AlbrechtS
Fix Version:1.4.0
Fix Commit:6f7e1f4fb7e1277b4e28a15874db449cef2d6bfc
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 jlp2
13:00 Sep 09, 2013
fl_dnd_leave_event.diff
0k
 
 
#2 AlbrechtS
05:12 Sep 25, 2014
dnd_leave.cxx
6k
 
 
#3 jlp2
05:53 Sep 25, 2014
dnd_leave_fl_window.cxx
1k
 
 
#4 AlbrechtS
08:44 Sep 25, 2014
fl_dnd_leave_event_v2.diff
0k
 
 
#5 AlbrechtS
08:54 Sep 25, 2014
dnd_leave_fl_window_v2.cxx
1k
 
 
#6 AlbrechtS
03:01 Oct 17, 2014
dnd_leave_fl_window_handle.cxx
1k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#1 jlp2
13:00 Sep 09, 2013
Using the current FLTK 1.3.2 release the FL_DND_LEAVE event is never passed to an overridden handle() function.

I think this is because in the Fl::handle_() function in Fl.cxx, there is a return statement instead of a break statement. I attached a .diff file that shows the change I made to get it to work. Maybe someone who knows the code better could verify if this solution is correct and if there are similar bugs for the other cases (event types).
 
 
#2 AlbrechtS
05:12 Sep 25, 2014
Your widget must return 1 on FL_DND_ENTER to get FL_DND_DRAG and FL_DND_LEAVE events (related to the current drag operation). Note that you can get other (unrelated) FL_DND_LEAVE events due to how FLTK's event propagation works.

See the attached demo program dnd_leave.cxx for a working test case. This is derived from test/subwindow.cxx. Compile with

fltk-config --compile dnd_leave.cxx

then run the program and drag some text (from the input widgets or another program window) over the two widgets labeled "enterexit1" and "enterexit2" and watch the color changing to yellow and back to default when leaving the widget.

The events will be output to stdout if you run the program with an attached console, which will work with MinGW but maybe not with standard Windows programs compiled with MS VC++.

Please confirm that returning 1 on FL_DND_ENTER works for you.

If it does not work, please post a small and compileable example program (like dnd_leave.cxx) so that we can see the issue.

Note that this STR will be closed if we don't get a response within a reasonable time (about two weeks).
 
 
#3 jlp2
05:53 Sep 25, 2014
The test case you described and posted works for me, too. So maybe the problem does not occur for all widgets types. However, I still have the problem for Fl_Window widgets. I also attached a small example program. Just drag a something (like a file or text from another program) over the window. FL_DND_ENTER and FL_DND_DRAG are fired, FL_DND_LEAVE is not.  
 
#4 AlbrechtS
08:08 Sep 25, 2014
Okay, I see. This needs more investigation, I'll take a look into it.

Thanks for posting the test program.
 
 
#5 AlbrechtS
08:54 Sep 25, 2014
I posted a new patch fl_dnd_leave_event_v2.diff against svn r 10336 - nothing else changed.

At a first glance and test, the patch makes FLTK send FL_DND_LEAVE events to windows, so this part seems okay. Thanks for the patch, BTW.

Meanwhile I used a modified test program with an embedded window (uploaded as dnd_leave_fl_window_v2.cxx), and this works as expected with the given patch. I can see the FL_DND_LEAVE events sent to the outer window in both cases: leaving the window to the inner window, or leaving it to the outside. So far, so good.

However, I'm still concerned whether there are side effects, because other widgets _got_ FL_DND_LEAVE events before. I'm not keen on sending even more FL_DND_LEAVE events to other widgets - or something like this.

I'm going to check this later...
 
 
#6 AlbrechtS
03:01 Oct 17, 2014
Looks like I made a step forward.

I found that your test program was missing an essential part: calling the handle() method of the base class. If I add this, I get the normal behavior that FL_DND_LEAVE is also sent to the derived window class.

Please see attached file dnd_leave_fl_window_handle.cxx which is a modified version of your test program dnd_leave_fl_window.cxx. This works as expected. Here is an example output:

   1 - outer       , Event: 20 - FL_DND_ENTER
   2 - outer       , Event: 21 - FL_DND_DRAG
   3 - outer       , Event: 22 - FL_DND_LEAVE
   4 - outer       , Event: 20 - FL_DND_ENTER
   5 - outer       , Event: 21 - FL_DND_DRAG
   6 - outer       , Event: 22 - FL_DND_LEAVE

Hence I believe now that your program is faulty, although it LOOKS strange that there is a return statement and not a break in fl_handle() as you pointed out.

From my current point of view this is not going to be "fixed" in FLTK 1.3.3 - if at all (I'm postponing further analysis). I reduced the priority to 2 (Low) for now.

Please check your original program and test if calling the handle() method of the base class (probably Fl_[Double_]Window::handle()) fixes the issue for you. Please don't forget to revert any changes in your FLTK code, if you were using a self-patched version.
 
 
#7 jlp2
03:57 Oct 21, 2014
Okay, great, I can confirm the code works when calling the handle() method of the base class.

My example was guided by yours, where "EnterExit::handle" doesn't call the handle method of the base class, too. So was your example also faulty? Should the call to the handle method of the base class be needed or not or for some specific widgets only? Maybe the correct way should be described more clearly in the docs. The docs for the "handle" method say "most of the time, you want to call the inherited handle() method in your overridden method so that you don't short-circuit events that you don't handle". It seems that either a) the the inherited handle() method should always be called even if the event is already handled by a component or b) the FLTK library code should be fixed (using the proposed patch or something similar).
 
 
#8 AlbrechtS
08:00 Oct 22, 2014
Faulty or not - hard to say. The docs are (maybe intentionally) not very clear, but they say "most of the time...". This is one case where you certainly need it. In windows it seems to be clear that you have to propagate all events to their child widgets. It may not be as obvious for FL_DND_*, but as it is now, it seems to be so.

In general there may be cases where you want to preclude events from being handled by the base class. One example is a kind of input filter in input widgets. If your derived widget doesn't want that particular key (character) to be entered (e.g. non-numeric keys in numeric input fields), then you would definitely not call the base class's handle(). However, in my opinion you must return 1, because your widget "consumed" the event (maybe by ringing a bell or other visual feedback). Hence it depends...

That said, I'll leave this STR open for further investigation whether the patch provided by you can or should be applied. Currently I can't say, so I won't apply it for now.

Anyway, I'm glad your problem is resolved, and thanks for the patch.
 
 
#9 AlbrechtS
06:28 Nov 17, 2023
Fixed in Git repository.

I decided to clarify the docs on event processing, particularly the phrase "Most of the time, you want to call the inherited handle() method ..." in Fl_Widget::handle().

Since the OP's issue (STR) has been resolved I'm closing this STR.
 
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.