Menu
▾
▴
#2797 Labelframe loses border and title when it's a container
closed-wont-fix
4
2011-04-04
2010-05-06
No
This happened with Tk 8.5.8 from the Debian repositories. Labelframes created with "-container true" and I passed their [winfo id] as values for argv {-use} while creating slave interpreters. The slaves windows were embedded in the labelframes areas, but they lost their borders and titles. I don't know how labelframe widgets are designed, but it seems that [winfo id] on a labelframe returns the ID of its "outer", container frame, not of its interior as expected.
Thanks!
Fabricio Rocha
Brasilia, Brasil
rocha_fabricio@yahoo.com.br
Probably shouldn't be a -container option on a labelframe (it has no specific "internal" widget as such). Put it on a normal frame inside the labelframe instead.
The border of a container widget is not respected by an embedded widget. This is true both for a frame and a labelframe, but more evident in a labelframe which has a default border. Also this was true for a frame before the labelframe was added, so nothing new in principle.
I guess there are two options.
1. Fixing it. Should be possible, but meddles in platform dependent code that is tricky to test. The risk for breaking stuff is evident.
2. Clearly document the limitation. Deprecate -container from labelframe and mention in frame that -borderwidth, -padx and -pady are ignored in a container.
So is it worth fixing?
I'd be tempted to say that labelframe just shouldn't have -container at all.
Updated documentation to reflect this limitation.