Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Strange behaviour of text widget
9 views
Skip to first unread message
Rob
Feb 7, 2012, 4:48:58 AM2/7/12
to
I have written the following code which reproducibly causes a strange
result. The text string used as input is actually 176 characters long
(according to the 'string length' command). Just in case it matters, this
text string contains with no internal line breaks.
text .txt -width 55 -wrap word
label .lbl -bg cyan3
pack .lbl -side top -fill x
pack .txt -side left
set comment "Science fiction author, journalist, and all around futurist
Cory Doctorow believes the recent copyright battles are the opening salvo of
a larger war against general computers."
.txt delete 1.0 end
.txt insert 1.0 $comment
update idle
set txtLines [.txt count -displaylines 1.0 end]
puts $txtLines
....
....
When the 'update idle' line of code is *not* used, the output from the puts
statement is 176. When the update line IS used, the result is 4.
Given that I was trying to get the count of the display lines produced,
these outcomes are confusing. From the visual evidence (text box), 4 is
obviously the correct outcome.
I have no idea what is causing this strange behaviour so am posting it here
so someone with a detailed understanding of the internals behind the text
widget can see it and offer an explanation and indication of whether I
should post a bug report.
TIA
Rob.
result. The text string used as input is actually 176 characters long
(according to the 'string length' command). Just in case it matters, this
text string contains with no internal line breaks.
text .txt -width 55 -wrap word
label .lbl -bg cyan3
pack .lbl -side top -fill x
pack .txt -side left
set comment "Science fiction author, journalist, and all around futurist
Cory Doctorow believes the recent copyright battles are the opening salvo of
a larger war against general computers."
.txt delete 1.0 end
.txt insert 1.0 $comment
update idle
set txtLines [.txt count -displaylines 1.0 end]
puts $txtLines
....
....
When the 'update idle' line of code is *not* used, the output from the puts
statement is 176. When the update line IS used, the result is 4.
Given that I was trying to get the count of the display lines produced,
these outcomes are confusing. From the visual evidence (text box), 4 is
obviously the correct outcome.
I have no idea what is causing this strange behaviour so am posting it here
so someone with a detailed understanding of the internals behind the text
widget can see it and offer an explanation and indication of whether I
should post a bug report.
TIA
Rob.
Arjen Markus
Feb 7, 2012, 5:27:08 AM2/7/12
to
_without_ the "update idle" command, I do understand why there is a
difference. You get similar problems/variations when you try to
create a PostScript file with the contents of a canvas.
The thing is that the text widget has not been able to fully
accommodate
its contents with respect to the available geometry. Quite possibly,
as with the canvas, it has to assume that its size is minimal (in this
case: one character wide) until it can negotiate with the containing
widget what its size will be.
The "update idle" command causes this negotiation to occur rightaway.
Once it is done, the text widget can properly compute how many
characters
it can show at each display line.
Regards,
Arjen
Rob
Feb 7, 2012, 8:23:33 AM2/7/12
to
Arjen Markus wrote:
> On 7 feb, 10:48, Rob <dislexic_wob...@NOSPAMyahoo.com> wrote:
>> I have written the following code which reproducibly causes a strange
>> result. The text string used as input is actually 176 characters long
>> (according to the 'string length' command). Just in case it matters, this
>> text string contains with no internal line breaks.
>>
>> text .txt -width 55 -wrap word
>> label .lbl -bg cyan3
>>
>> pack .lbl -side top -fill x
>> pack .txt -side left
>>
>> set comment "Science fiction author, journalist, and all around futurist
>> Cory Doctorow believes the recent copyright battles are the opening salvo
>> of a larger war against general computers."
>>
> On 7 feb, 10:48, Rob <dislexic_wob...@NOSPAMyahoo.com> wrote:
>> I have written the following code which reproducibly causes a strange
>> result. The text string used as input is actually 176 characters long
>> (according to the 'string length' command). Just in case it matters, this
>> text string contains with no internal line breaks.
>>
>> text .txt -width 55 -wrap word
>> label .lbl -bg cyan3
>>
>> pack .lbl -side top -fill x
>> pack .txt -side left
>>
>> set comment "Science fiction author, journalist, and all around futurist
>> Cory Doctorow believes the recent copyright battles are the opening salvo
>> of a larger war against general computers."
>>
>> When the 'update idle' line of code is *not* used, the output from the
>> puts statement is 176. When the update line IS used, the result is 4.
>>
>> Given that I was trying to get the count of the display lines produced,
>> these outcomes are confusing. From the visual evidence (text box), 4 is
>> obviously the correct outcome.
>>
>
>> puts statement is 176. When the update line IS used, the result is 4.
>>
>> Given that I was trying to get the count of the display lines produced,
>> these outcomes are confusing. From the visual evidence (text box), 4 is
>> obviously the correct outcome.
>>
>
> While I am not sure why you get 176 as the outcome of the program
> _without_ the "update idle" command, I do understand why there is a
> difference. You get similar problems/variations when you try to
> create a PostScript file with the contents of a canvas.
>
> The thing is that the text widget has not been able to fully
> accommodate
> its contents with respect to the available geometry. Quite possibly,
> as with the canvas, it has to assume that its size is minimal (in this
> case: one character wide) until it can negotiate with the containing
> widget what its size will be.
>
> The "update idle" command causes this negotiation to occur rightaway.
> Once it is done, the text widget can properly compute how many
> characters
> it can show at each display line.
Arjen
> _without_ the "update idle" command, I do understand why there is a
> difference. You get similar problems/variations when you try to
> create a PostScript file with the contents of a canvas.
>
> The thing is that the text widget has not been able to fully
> accommodate
> its contents with respect to the available geometry. Quite possibly,
> as with the canvas, it has to assume that its size is minimal (in this
> case: one character wide) until it can negotiate with the containing
> widget what its size will be.
>
> The "update idle" command causes this negotiation to occur rightaway.
> Once it is done, the text widget can properly compute how many
> characters
> it can show at each display line.
Thank you for the explanation. The 176 characters is the length of the input
string, so I was concerned that somehow the text widget was reverting to
counting the number of characters rather than the number of display lines
which I actually requested - so maybe a bug of some sort!
What you've said explains the behaviour perfectly. Should a warning that
this sort of behaviour might occur be put into the documentation so a
developer using the text widget is prepared for what looks like a
behavioural problem (but as you've pointed out, is not!)? And the use of the
"update idle" command as a 'work around'.
Rob
0 new messages