Automatically Setting Minimum Size of a Dialog edit

After packing or gridding a Tk dialog, the window can be resized at will by the user unless a minsize/maxsize has been specified or the wm resizable command has turned off resizing. This allows the user to shrink the dialog to smaller than the original size arrived at after packing/gridding. If you want to fix the minimum size to be that which has been decided by the pack/grid managers, pass your window to the proc shown below after you have packed/gridded all dialog elements:

   proc setDialogMinsize {window} {
      # this update will ensure that winfo will return the correct sizes
      update

      # get the current width and height
      set winWidth [winfo width $window]
      set winHeight [winfo height $window]

      # set it as the minimum size
      wm minsize $window $winWidth $winHeight
   }

Pass a window into this proc and it will set its minimum size to be whatever size it is currently. You will be able to make the window larger obviously (unless you set a wm maxsize on it).

It would be good if there was a wm-like command to do this automatically. (is there?)

-- Michael Eisemuth

---

AMG, 24 Nov 2006: I use a binding to avoid [update]:

 bind $win <Configure> {
    bind %W <Configure> {}
    wm minsize %W [winfo width %W] [winfo height %W]
 }

In the previous version of my edit I griped about this not working correctly for windows with menubars, but this seems to have been fixed at some point between 8.4 and 8.5a4. Now [wm minsize] sets the minimum size for the . "frame", not including the menubar, whose size is very difficult to determine.

[anonymous Ameritech/AT&T ADSL user]: Be aware when you put a binding on a toplevel window, that binding applies to *all* children of that widget. It's best to put some sort of check in the binding to make sure it only runs for the actual toplevel, or add an additional bindtag just to the toplevel and bind to that instead of to the toplevel.

AMG: Yes, I had that problem once, but it was only once, and I fixed it by moving the [bind] a little lower down in my code. Apparently it's a rare thing for a non-toplevel to be <Configure>'d before its toplevel, at least the way I design dialogs. But that check is a good idea: Only do the work if %W equals $win.