> 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
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
