| | [ Return to Bugs & Features | Post Text | Post File | Prev | Next ]
STR #3528
| Application: | FLTK Library |
|---|
| Status: | 5 - New |
|---|
| 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_Tree: dragging an item over a widget() can cause FL_RELEASE to be ignored |
|---|
| Version: | 1.4-current |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
| |
| #1 | greg.ercolano
17:04 Aug 27, 2019 |
| To replicate:
1. Run test/tree
2. Change "Selection Mode:" to Single+Drag
3. Drag 'Ddd' up and over the "ccc button" and release mouse to drop
The drop is ignored.
FL_RELEASE is being sent to the tree's handle() method but it's being
ignored, probably because the release is inside the widget(). It should
be handled by the tree due an item being actively dragged. | |
| |
| #2 | AlbrechtS
05:44 Aug 28, 2019 |
| I looked into it (git commit 8c39007b26 as of today) ... and yes, it seems to be true that Fl_Tree::handle() calls Fl_Group::handle() at line 374 and eclipses FL_DRAG and other events from further handling in Fl_Tree if a widget handles the event, i.e. returns 1.
The question I see here (in general) is "what is intended by the user" when they drop anything (not further specified) on a widget which is embedded in the tree? Do they expect the widget to handle the FL_DROP event (whatever it may do with it), or do they expect the Fl_Tree to handle the FL_DROP event and maybe move an item around? I don't know... | |
| |
| #3 | AlbrechtS
05:48 Aug 28, 2019 |
| While we're at it (a little code review): I found some redundant and maybe confusing code in Fl_Tree::handle() - as mentioned above, code as of today, commit 8c39007b26.
int ret = 0;
is defined early in handle() at line 227 (OK).
The statements at line 319 and 322 (ret = 1;) are redundant and should be removed. This value is not used because there is 'return(1);' at line 324. It's also possible to change this to 'return(ret);' but I think 'return(1);' is more explicit and to be preferred here.
That said, the statement at line 381 (after calling Fl_Group::handle())
if ( ! _root ) return(ret);
could also be written as:
if ( ! _root ) return(0);
because at this point in the code 'ret' is always zero.
The following statements use 'ret' correctly AFAICT.
Just my 2 ct. | |
| |
| #4 | AlbrechtS
06:03 Aug 28, 2019 |
| Note: I wrote "FL_DROP" in comment 2 but this should read "FL_RELEASE" of course.
Regarding a possible solution (just a thought): you could probably call Fl_Group::handle() later *after* handling FL_DRAG and other events if and only if the event was not handled by Fl_Tree. I see that there are some status variables, for instance (in 'case FL_DRAG'):
if ( _lastpushed == PUSHED_NONE ||
_lastpushed == PUSHED_OPEN_CLOSE ) return 0;
etc.. Would it make sense to handle the FL_RELEASE event only if an Fl_Tree object (item) was pushed/dragged/released and call Fl_Group::handle() later and only if the event was NOT handled by Fl_Tree::handle()?
Technically speaking: set the above mentioned 'ret' variable to 1 if we handled the event and call Fl_Group::handle() only if ret == 0 ? Or something like this... | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
FLTK Apps 
