f



tcl text widget wrap around?

Hi,

I am using a proc to detect the occurrence of certain string in a text 
widget. It works by periodically scan each line of the text widget 
(starting at the current line), check content, decrement line number if 
not matched, *repeats, until it reaches line 0.

The problem is that it appears the text widget's line number will 
eventually wrap around after awhile, so it is possible that the current 
line index sits close to 0.

Is there any easy way around this problem? How can I tell a text 
widget's buffer size?


Thanks
0
py
3/27/2011 1:16:32 PM
comp.lang.tcl 23429 articles. 2 followers. Post Follow

5 Replies
1224 Views

Similar Articles

[PageSpeed] 3

On 3/27/11 8:16 AM, py wrote:
> Hi,
>
> I am using a proc to detect the occurrence of certain string in a text
> widget. It works by periodically scan each line of the text widget (starting
> at the current line), check content, decrement line number if not matched,
> *repeats, until it reaches line 0.
>
> The problem is that it appears the text widget's line number will eventually
> wrap around after awhile, so it is possible that the current line index sits
> close to 0.
>
> Is there any easy way around this problem? How can I tell a text widget's
> buffer size?

It is not documented as wrapping!  This sounds like a bug.

What version of Tcl/Tk are you using?

What platform?

What value are you seeing it wrapping at?


-- 
+------------------------------------------------------------------------+
| Gerald W. Lester, President, KNG Consulting LLC                        |
| Email: Gerald.Lester@kng-consulting.net                                |
+------------------------------------------------------------------------+
0
Gerald
3/28/2011 12:35:14 AM
On Mar 27, 9:16=A0am, py <pyj...@shaw.ca> wrote:
> ... It works by periodically scan each line of the text
> widget (starting at the current line), check content,
> decrement line number ifnot matched, *repeats, until it
> reaches line 0. ...

Is there some reason why you are searching in this manner rather than
simply utilizing the built in "search" function with the -backwards
option if you want to look from point X back to the start?
0
Rich
3/28/2011 1:12:01 AM
On 3/27/2011 5:12 PM, Rich wrote:
> On Mar 27, 9:16 am, py<pyj...@shaw.ca>  wrote:
>> ... It works by periodically scan each line of the text
>> widget (starting at the current line), check content,
>> decrement line number ifnot matched, *repeats, until it
>> reaches line 0. ...
>
> Is there some reason why you are searching in this manner rather than
> simply utilizing the built in "search" function with the -backwards
> option if you want to look from point X back to the start?

There is one: I don't know too much about tcl :)

The search -backward make things simpler, but I still need to solve the 
index wrap around issue. I need the ability to limit search to within a 
certain proximity from the last update to the text widget (so that I 
don't end up finding staled string that repeats).

I did a simple experiment, put one line into text, read the index. I 
found that a loop around occurs at line 501, which loops back to 453. I 
have no idea where these values come from. When I am using the widget, I 
have seem the Y index goes up to 630. So it seems there is something 
that triggers looping

PS: the text widget is used as a terminal console, this line shows its 
creation

text $top -width 45 -height 20 -yscrollcommand "$top.scrY set" 
-xscrollcommand "$top.srcX set" -wrap none -font {{Courier New} 10} 
-background #d9dab1
0
pyjunk (62)
4/2/2011 7:35:34 AM
On 4/1/2011 11:35 PM, py wrote:
> On 3/27/2011 5:12 PM, Rich wrote:
>> On Mar 27, 9:16 am, py<pyj...@shaw.ca> wrote:
>>> ... It works by periodically scan each line of the text
>>> widget (starting at the current line), check content,
>>> decrement line number ifnot matched, *repeats, until it
>>> reaches line 0. ...
>>
>> Is there some reason why you are searching in this manner rather than
>> simply utilizing the built in "search" function with the -backwards
>> option if you want to look from point X back to the start?
>
> There is one: I don't know too much about tcl :)
>
> The search -backward make things simpler, but I still need to solve the
> index wrap around issue. I need the ability to limit search to within a
> certain proximity from the last update to the text widget (so that I
> don't end up finding staled string that repeats).
>
> I did a simple experiment, put one line into text, read the index. I
> found that a loop around occurs at line 501, which loops back to 453. I
> have no idea where these values come from. When I am using the widget, I
> have seem the Y index goes up to 630. So it seems there is something
> that triggers looping
>
> PS: the text widget is used as a terminal console, this line shows its
> creation
>
> text $top -width 45 -height 20 -yscrollcommand "$top.scrY set"
> -xscrollcommand "$top.srcX set" -wrap none -font {{Courier New} 10}
> -background #d9dab1


Opps, never mind, I have spot the evildoer code. Someone put some very 
strange stuff here that keeps deletes entry when the line counter goes 
above 500. Now it all makes sense
0
pyjunk (62)
4/2/2011 7:46:44 AM
py <pyjunk@shaw.ca> writes:

> > The search -backward make things simpler, but I still need to solve the
> > index wrap around issue. I need the ability to limit search to within a
> > certain proximity from the last update to the text widget (so that I
> > don't end up finding staled string that repeats).

> > I did a simple experiment, put one line into text, read the index. I
> > found that a loop around occurs at line 501, which loops back to 453.
> 
> Opps, never mind, I have spot the evildoer code. Someone put some very
> strange stuff here that keeps deletes entry when the line counter goes above
> 500. Now it all makes sense

That sonds like someone else's strategy for dealing with the
problem of "proximity from the last update" by automatically 
deleting "staled string that repeats".


-- 
Donald Arseneau                          asnd@triumf.ca
0
asnd (4601)
4/2/2011 11:42:54 PM
Reply: