I'm working with the tree view widget.
The text I'm displaying in the first column is too long for the column
width and it gets printed on top of the text in the second column.
When I resized column zero - the second column resized. I've noticed
this behavior when adding column headings - I don't seem to be able to
configure the first column.
Also, generally resizing columns - the drawing of the text is bad when
the column width becomes too narrow.
Has anyone else any experience of this widget?
I'm thinking it make be better to return to the more familiar (to me)
Bwidget set.
Thanks
Glenn
I mean programtically. I guess I'm talking about the item text column.
I.e. the left most column where the -text of an inserted item is
displayed.
I don't seem to be able to set the heading for this column.
It's the column where 'abc' is displayed in the script below.
package require tile
ttk::treeview .wtreeResults -columns "col1 col2"
# Set headings for the columns - this names Columns 2 and 3 as seen on
the screen. E.g. the ones where values are displayed.
.wtreeResults heading col1 -text "Column 1"
.wtreeResults heading col2 -text "Column 2"
grid .wtreeResults -row 0 -sticky news
.wtreeResults insert {} end -id item1 -text "abc" -values "123 456 789"
.wtreeResults insert {} end -id item2 -text "some really unusually long
text in here causes overwiting" -values "123 456 789"
update
after 2000
# This expands the first value column - I want to be able to expand the
item text clumn.
.wtreeResults column 0 -width 500
vwait forever
The script also shows the 2nd column (first value) being overwritten by
the first column (text). To deal with this I tried to resize the first
column but as mentioned above the tree widget column 0 seems to be the
second column on the screen.
I hope this helps explain my problem better.
Column sizing could be easier for me if I could specify width as number
of characters.
Also a line wrap option would be good.
e.g:
# Here's the text for my item.
set lText "a long item in the tree"
# Insert the item into the tree.
.wtreeResults insert {} end -id item1 -text $lText -values "123 456 789"
# Resize the item text column to the same width as the item text.
pathname -column 0 -width [string length $lText]
# Alternatively.... Use the default item text column width and wrap the
text if necessary.
pathname -column 0 -wrap true
I have tried putting text with carriage returns in a value column - I
had to escape the quotes for this to work.
See script below:
package require tile
ttk::treeview .wtreeResults -columns "col1"
.wtreeResults heading col1 -text "Column 1"
grid .wtreeResults -row 0 -sticky news
.wtreeResults insert {} end -id item1 -text "abc" -values \"123\n456\n789\"
vwait forever
I hope this helps.
I can carry on playing with ttk::treeview for a while as this is a home
project, not work. Do you expect to be able to make changes in the near
future?
Thanks
Glenn
I'm now automatically resizing my column to a width of (string length *
6.5) after I insert the string.
I'm not sure if this will be reliable on other systems though.
cheers
Glenn
Joe English wrote:
> glennh wrote:
>
>>I mean programtically. I guess I'm talking about the item text column.
>>I.e. the left most column where the -text of an inserted item is
>>displayed.
>>I don't seem to be able to set the heading for this column.
>>It's the column where 'abc' is displayed in the script below.
>>[...]
>>.wtreeResults column 0 -width 500
>
>
> Try ".wtreeResults column #0 -width 500" instead
> (note "#0", not "0". "0" refers to the first data
> column, "#0" refers to the first display column;
> see section "COLUMN IDENTIFIERS" in the man page.)
>
>
>>I have tried putting text with carriage returns in a value column - I
>>had to escape the quotes for this to work.
>>[...]
>>.wtreeResults insert {} end -id item1 -text "abc" -values \"123\n456\n789\"
>
>
> The -values option is a list; you probably want:
>
> .wtreeResults insert {} end -text "abc" -values [list "123\n456\n789"]
>
> Except that, at the moment, the treeview widget doesn't
> handle multi-line data column values, so that won't really
> work either just yet.
>
>
> --Joe English
>