On 02.05.2012 16:27, chris wrote: [Manolo wrote] >> I believe the correct solution would be to proceed as done >> by Fl_Value_Input that embeds, as a member, an Fl_Input object >> called input. This way, the Fl_Value_Input::draw() function can call >> Fl_Input::draw() as follows: >> Fl_Widget *w =&input; >> w->draw(); >> Function Fl_Value_Input::handle() can also call Fl_Input::handle(). >> >> The key point is that Fl_Value_Input is not a subclass of Fl_Input, >> but uses an Fl_Input object as one of its members.
And that's a source of problems. A better solution would be to derive Fl_Value_Input from ... (a) Fl_Input, or (b) Fl_Group. The former, because it extends Fl_Input (that would be the logical way, IMHO); the latter because we need an Fl_Group for drawing and event handling to work correctly with multiple widgets that don't share a common area (that's how FLTK works). > - You would have to use several "kludges" as can be seen in > Fl_Value_Input.cxx Yep, this "parent" pointer kludge is really a mess. I learned it the hard way, believe me :-( > So asking more generally: > Would it be bad to have proteced access to the draw() method? No. > Would there be any disadvantages? No (AFAICT). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
