> I really don't want to get into an argument over this.
> I happen to think that having a single Calendar instance shared by
> all DateInput instances is a reasonable design
Yes; that's why when I mentioned the SetCalendar() approach,
I tried to underline it still lets you do that in this paragraph:
>> [..]
>> d->SetCalendar(c); // attach it to the DateInput class here
>> [..]
>> In this case DateInput::SetCalendar() can either affect only
>> the single instance of DateInput(), or all instances, depending
>> on if you implement the internal pointer as a static or not.
But if your goal is to define the Calendar inside the
DateInput's ctor, I think you can still do that, without
the current() stuff. According to this line from the Fl_Window docs:
"This widget produces an actual window. This can either be a main window,
[..] or a "subwindow" inside a window. This is controlled by whether or not
the window has a parent()."
That last line seems to imply that maybe all that's needed is to put:
parent(0);
..to the top of Calendar's ctor. That might force it to be a separate
window, and without affecting the widget hierarchy.
Then I'd think there'd be no need for the current() stuff at
all in the DateInput widget.
> It works. It just doesn't make me happy.
I agree, I don't think current() should need to be called at all.
>> So the 'missing end()' is the one called in main().
> Sorry, but that makes no sense.
When I said the 'missing end()' was the one in main, it was
just about context; the Calendar (as was written) assumed
the widget hierarchy was end()ed.
By moving the creation of the Calendar into the DateInput
ctor as you did, caused the end() to 'become missing'
from Calendar's point of view.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
