[..]
> Yes, but I think the OP is regarding FLTK2 (subject of this thread).
>
> I think the FLTK folks have done what they can to get rid of
> the implied begin() by taking it out in FLTK2.
I was (and continue to be) trying to expand the discussion in a
hopefully productive direction. What I am talking about has nothing
to do with the implied begin(), and applies equally to fltk 1 and 2.
Let me try an example.
class C {
Fl_Window* win_;
// no copies allowed
C(C const&);
C& operator=(C const&);
public:
C(int w, int h) : win_(new Fl_Window(w, h)) {;}
};
I think it would be uncontroversial to say that there's nothing
fundamentally wrong with this skeleton as a design. However, if
the intent is to create a top-level window, there's a problem. To
find out how to fix it, we can peek into the fltk source code. This
is from fl_ask.cxx:
// make sure that the dialog does not become the child of some
// current group
Fl_Group *previously_current_group = Fl_Group::current();
Fl_Group::current(0);
// create a new top level window
Fl_Window *w = message_form = new Fl_Window(410,103,"");
Okay, so now we know. Now, I don't personally care much for this
style of coding, but it's imposed by the begin/end paradigm, and
only a very experienced fltk user would think of it, imo. That's
why I think it should be explained carefully in the docs.
Cheers,
Stan
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
