On 10.05.2011 23:50, Ian MacArthur wrote: > As to how you might work around it, is it possible to derive your own > container widget from Fl_Group, and then override the add() method such that > it takes in the widget you pass it, determines the widget's x,y co-ords, adds > on it's own x,y co-ords then does a widget->position(newx,newy) before > actually calling the base class add() on the widget... > > Something like that might work, at least for widgets that you explicitly > add() to your group... Not sure how it would fly with widgets that were > implicitly added to your group by the group->begin()/end() stuff though. > > Anyone have a view on that?
I'm afraid it wouldn't work :-( Fl_Widget's c'tor does this: if (Fl_Group::current()) Fl_Group::current()->add(this); The problem here is that Fl_Group::add() is not virtual, and therefore Fl_Group::add() will be called and not the derived container widget's add() method. IMO this is a deficiency that ought to be fixed in one of the next steps (maybe 1.4.0?). This is definitely an ABI breaking change, and doing it now (in 1.3.0) would mean to risk some subtle side effects - maybe. This relates to many group changing methods, BTW, e.g. also remove(), clear(), resizable(), ..., and maybe also child(int) and even children() [1]. Albrecht [1] Think of Fl_Scroll and its two scrollbars as children. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
