On Jun 27, 2007, at 2:54 AM, Daniel wrote:
> but what about:
>
> out1 = new Fl_Output( group, .. );
> out2 = new Fl_Output( group, .. );
> but1 = new Fl_Button( group, .. );
> but2 = new Fl_Button( group, .. );
>
> The add still takes place in the base widget class constructor,
> but rather than a system wide static pointer the constructor
> has a line such as:
>
> widget::widget( widget* parent, .. ) {
> ..
> parent->add( this );
> }; // end widget constructor
This particular interface was developed about 12 years go. I am not
sure anymore, why it was decided to it this way. But to me, the
advantage is a less cluttered constructor. Three arguments is a good
number for function calls. Any more will tend to generate multi-line
wormcode.
I'd like to ask you back, though: what is bothering you about the
current interface? The static variable is not system global, but
application global, which is fine as we do not allow multithreading
during widget creation for other reasons anyway.
Oh, I just remembered one reason for the design. You can write
classes that have children created in the construtor. This would
otherwise not be possible because the 'this' pointer is not available
yet. The only alternative would be to put pointers in the class.
class My_Composite : public Fl_Group {
My_Composite(int x, int y, int w, int h, const char *l=0L);
Fl_Input input;
Fl_Button upArrow;
Fl_Button downArrow;
Fl_End end;
};
My_Composite::My_Composite(int x, int y, int w, int h, const char *l)
: input(x, y, w-20, h, l),
upArrow(x+w-20, y, 20, h/2),
downArrow(x+w-20, y+h/2, 20, h/2)
{
}
Matthias
----
http://robowerk.com/
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
