FLTK logo

Re: [fltk.coredev] Proposal: adding FL_WHEN_DELETING and the event FL_DELETING

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 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Proposal: adding FL_WHEN_DELETING and the event FL_DELETING Albrecht Schlosser Oct 26, 2022  
 
On 10/26/22 12:29 'melcher....@googlemail.com' via fltk.coredev wrote:
Problem:

When adding user_data in callbacks, it is difficult to make sure that the user_data is deleted when the widget is deleted, especially when deleting a group auto deletes all children.

Solution:

Add FL_WHEN_DELETING to Fl_Widget::when(), so before deleting a widget, the user can receive a callback and get a chance to clean up. The reason for the callback would be indicated by setting Fl::event() to FL_DELETING, which would also be sent to Fl_Widget::handle(int).

Interesting.

Thinking about it ... Hmm, I don't think that sending a callback to the *widget* that is about to be deleted is enough (see below). Generally this is already done by calling its destructor. Sure, using the destructor involves subclassing whereas sending a callback could be handled w/o subclassing. Maybe it's useful to add for cases where the widget itself "knows" what to do.

But how does the (child) *widget* "know" what its parent class needs to do, i.e. what to clean up if it's a child of a group? The parent can be any type of group, e.g. Fl_Pack, Fl_Flex, Fl_Grid, or Fl_Scroll and the child widget doesn't necessarily know what subclass of Fl_Group its parent is. This would need to be hardcoded in the callback (which might work). The removal of the widget from its parent group is done anyway in the destructor of the widget, and this notifies the Fl_Group widget.

The latter is where my new proposal kicks in: container classes like Fl_Scroll, Fl_Flex, Fl_Grid etc. can opt in for notification that a child is about to be added, moved inside the group, or removed by implementing a new virtual method and can do whatever they need. Hence the "callback" (virtual method) is delivered to the parent class directly. This is what I implemented but not yet published because I was still working on it.

Conclusion:

Maybe both approaches can have a value in different contexts of a program. A user (program) may want to know when a widget is deleted to clean up specific widget related data but my current problem is more about the parent of the widget that needs to know when a child is deleted because it (the parent) stores additional information about some or all children (Fl_Flex, Fl_Grid). This is independent of the widget's callback proposed above because it can't be "delegated" to the child to call the proper cleanup function of the parent group.

So, maybe "yes" to both approaches.

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/dade40ea-a2d0-b58c-6330-3bccf3f87647%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

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