> On 05/23/12 10:29, David Currie wrote: > > MyTextWindow(int W, int H,const char* l) > > : Fl_Window(W,H,l), MyTextDisplay(20,20,W-40,H-40,NULL) > > { > > Fl_Window::label(l); > > Fl_Window::add(this); // Compile error : ambiguous base class > > Fl_Widget > > Don't even do the add(); it's not needed. (**) > > FWIW, I wouldn't use multiple inheritance anyway, I'd just derive > from Fl_Window, and make MyTextDisplay a protected/private member, > and provide methods to manipulate the member separately, or provide > a single method that lets app code access it directly. That's the > common technique in FLTK apps, and is indeed how FLTK implements its > own derived widgets. > > ** add() is implied because Fl_Window::begin() is implied, > which handles add()ing all widgets that follow automatically > until an end(). > > So for instance, the following code: > > Fl_Window win(..); > MyTextDisplay myt(..); > win.end(); > > ..really ends up being: > > Fl_Window win(..); > win.begin(); // THIS IS IMPLIED > MyTextDisplay myt(..); // automatically a child of the win due to > implied win.begin() > win.end(); // end() the auto-parenting behavior of the > Fl_Window > ... > > ..which by definition does an add() already, so including an add() > after the MyTextDisplay declaration is redundant.
Thanks Greg, I didn't know these things were implied although I suppose it's logical from the examples. Please note for a purely CLEAN design, yes, MyTextDisplay is clearly a partof MyTextWindow(:Fl_Window) so it should be a private member. However, sadly, I happen to be a cheapskate nitpicker. Most of the methods I use are in MyTextDisplay and I am too cheap to pay the cost (space and time) of the extra fn call as well as the indirect referencing. For Example : int MyTextWindow::method(...) { return dispPtr->method(...); } Yes, I know one can have a method returning a pointer or a reference. But i assume its still cheaper as a typeof. I have noticed JAVA often has to do the above. There's lots of ways to do this but cheating with MyTextWindow : Fl_Window , MyTextDisplay as topmost(no add) does get a result (Fl_Window gets built first). In this case I am just LUCKY as FLTK's designers have covered up my lack of knowledge. I know this is not related directly to FLTK But out of interest and likely future need Class A ; Class B : A; Class C : A; Class D : B, C; How do you specify &D::C::A ? do have a result though _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev