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