Stan wrote:
>> Short rule: if you don't implement your own group resize method,
>> then call init_sizes() whenever you change widget dimensions
>> within a group, else you shouldn't need init_sizes() at all.
>>
>> Example:
>>
>> MyGroup::resize(int X, int Y, int W, int H)
>> {
>> Fl_Widget::resize(X,Y,W,H); // resize MyGroup [1]
>
> // if(parent()) parent()->init_sizes() ??
>> if (children()>0) {
>> for (int i=0; i<children(); i++) {
>> child(i)->resize(X+10*i,Y+10*i,10,10); // [2]
>> }
>> }
>> }
>
> Thanks. But what I'm still not getting is why I don't need
> the parent()->init_sizes() above. Didn't the first line "change
> widget dimensions within a [parent] group?"
Well, it does. But MyGroup::resize() is not "responsible" for
this change. The call to Fl_Widget::resize() honors the parent's
(or anybody else's) _request_ to change the group's size and/or
position.
The caller of MyGroup::resize() is responsible for calling
init_sizes() or not. And that depends on:
If this MyGroup::resize() is called, _because_ the parent
group resizes itself, then init_sizes() must not be called,
because you would otherwise delete the previously saved
initial group layout. And, as Greg explained, this would
result in the loss of the layout or at least in an aggregation
of rounding errors.
However, if this MyGroup::resize() is called, because you
want to _re_arrange things (like with the sidebar example),
then you must call init_sizes(), because you generate a
_new_ layout.
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
