FLTK logo

STR #3528

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 | Post Text | Post File | SVN ⇄ GIT | 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:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date 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 ]

 
 

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'.