Tcl Source Code

Logged In: YES 
user_id=79902

Firstly, these are not Tcl bugs, but problems with Tk.

Secondly, your first script works just fine for me.  Are you
sure it reproduces your problem?  (I suspect your problem is
warring geometry managers, which is a very well known
problem that is very awkward to solve without breaking a lot
of existing code.)

Thirdly, the 'propagate' behaviour is correct as it stands
(i.e. applying to masters, not children) since it has to be
that way to work correctly with nested uses of the same
geometry manager.

Logged In: YES 
user_id=59929

Hi,

Heres a simplified version of the actual code, I'm sure I
could reproduce the problem in normal tcltk, but your right
the above dosen't work.  Warring managers it no doubt the
cause :(.  The project I'm working on does however have a
lot of mixing depending on whats easier for that part of the
screen and who wrote the particular section of the code. 
Copy this to a file and run it in one go.

package require Iwidgets 3

####################################################################################################################
# Namespace/Class definitions
####################################################################################################################
class Chdwin {
    inherit itk::Widget

    constructor {args} {}

    # A custom window. You must create a title and position
the buttons.
    itk_option define -custom          custom         
Custom          0
}


proc ::chdwin {{args ""}} {
    uplevel ::Chdwin $args
}


# Object Constructor
body {Chdwin::constructor} {{options ""} args} {
    # Create a place for the user to place his own bits
    # Must be created before button box!
    itk_component add contents {
        frame $itk_interior.contents
    } {
        keep -background -width -height
    }

    # Create buttons
    set bbox $itk_interior.bbox
    frame $bbox

    #################################
    # Fix for button hightlight bug #
    frame  $bbox.resizeB   -highlightthickness 1
    frame  $bbox.menuB     -highlightthickness 1
    frame  $bbox.closeB    -highlightthickness 1
    #################################
    button $bbox.menuB.b   -width 11 -height 9 -borderwidth
2 -relief raised \
                           -padx 0 -pady 0
-highlightthickness 0
    button $bbox.resizeB.b -width 11 -height 9 -borderwidth
2 -relief raised \
                           -padx 0 -pady 0
-highlightthickness 0
    button $bbox.closeB.b  -width 11 -height 9 -borderwidth
2 -relief raised \
                           -padx 0 -pady 0
-highlightthickness 0

    # Setup bbox to contain all our buttons
    grid $bbox.menuB   -column 2 -row 0
    grid $bbox.menuB.b
    grid $bbox.resizeB -column 1 -row 0
    grid $bbox.resizeB.b
    grid $bbox.closeB  -column 0 -row 0
    grid $bbox.closeB.b

    pack  $itk_component(contents) -side bottom -fill both
-expand true
    pack  $bbox  -side left -fill y
    eval itk_initialize $options $args
}


configbody {Chdwin::custom} {
    if ($itk_option(-custom)) {
        pack $itk_interior.bbox  -in $itk_interior.contents
-side top -anchor ne -fill none
    } else {
        pack $itk_interior.bbox  -in $itk_interior -side
left   -fill y
    }
}


# Custom moves the button box into the contents to the user
# can build screens around it.
chdwin .c -custom 1
grid .c -sticky nsew


# Griding here kills tcl, but I really wanted the contents
# of the child window to be grided.
button .c.contents.b
grid   .c.contents.b


As for your the propagate I wasn't suggesting moving the
meaning of propagate to the children.  It's just the since
.f was grided it seems to make sense to set grid propagate
.f 0 since it's the gridder thats holding the geometery
information.  Setting pack propagate .f 0 is a little
confusing because the packer does not holding any details
about the widget .f.  Hence why a suggestion of when you
pack .f.b, the packer would say I must check the propagate
for .f.  Then it could say, hang on, I don't own .f but the
gridder does, perhaps I should ask the gridder for the
propagate...

In gerenal use though I have found no reason to be able to
set propagate independently for grid and pack.  When mixing,
we just set them both to the same value to avoid problems. 
If this approach was common perhaps a single propagate could
be held be the widget, and therefore be common between
between all managers.  The grid/pack propagate would then be
a way to set this common value.