#257 sashpos not set
The sashpos is not set correctly if set during creation of the panedwindow. Typically, just as window positions are cached and used for newly created windows, the same is true for sashpos. An after event with a sufficiently long time is needed for the sashpos to be set. The script below reproduces the problem with the current cvs (2007-02-13).
When doing $p sashpos before the layout is finished, perhaps it should be possible to store the requested value as
int reqSashPos;
and check this during first layout.
/Mats
package require tile
set w ._tilesashpos
toplevel $w
set p $w.p
ttk::panedwindow $p
$w.p add [text $p.t1 -height 10] -weight 1
$w.p add [text $p.t2 -height 10] -weight 1
$p.t1 insert end "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
$p.t1 insert end "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
$p.t2 insert end "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
$p.t2 insert end "1\n2\n3\n4\n5\n6\n7\n8\n9\n"
pack $p
wm geometry $w 400x200
puts "sashpos=[$p sashpos 0]"
after 10 $p sashpos 0 25
Logged In: YES
user_id=68433
Originator: NO
That's behaving more-or-less as expected -- sash positions are computed/updated during the geometry propagation dance, so [$pw sashpos $pane] doesn't always reflect reality unless preceded by [update] or [update idletasks].
Note also that [$pw sashpos] is a "semi-private" method -- it was only intended for use by the Panedwindow widget bindings, not for application code. Why do you need to know the sash position? Does [update] or [update idletasks] fix the problem?
Logged In: YES
user_id=108900
Originator: YES
The motive for being able to set the sashpos during widget creation is the same as being able to set a toplevel's size and position using wm geometry. An application typically stores a dialogs size and position in some prefs variable that is stored in a prefs file. The same is true for *setting* the sashpos.
An update or update idletask "fixes" it but that is a very bad habit to use update and a I don't think it should be necessary to do it.
Mats
Logged In: YES
user_id=68433
Originator: NO
Just realized something else that's probably relevant: sash positions are limited by the current size of the panedwindow. And the panedwindow is 1 pixel wide and 1 pixel tall until it becomes managed itself. This will prevent [$pw sashpos $sash $pos] from working properly before $pw is managed and mapped.
Logged In: YES
user_id=108900
Originator: YES
Couldn't then the sashpos be stored and used when the paned window is managed and mapped?
Mats
Logged In: YES
user_id=68433
Originator: NO
Setting sash positions should work better now (see recent message to tktable-tile-dev).
Summarizing: ttk::panedwindow now has -width and -height options; as long as you set those before setting sash positions, everything should work as expected.
You still need to call [update] before recording sash positions, and [update idletasks] is (typically) necessary before setting them.
Re: saving the requested sash position and using that at <Map>-time -- in order to make interactive resizing work properly, sash positions aren't the primary state variables; they're computed as a function of the slave request sizes, slave weights, and the overall available size.