Possible bug in Tk::Text

zakb has asked for the wisdom of the Perl Monks concerning the following question:

I've found what I consider to be a bug in Tk::Text 3.044 as provided with ActiveState on Windows.

The .pm file states that Greg London is the maintainer - as of 1999 - but has no other contact info.

Anyhow, the bug is that you can't amend the widget (with the insert method for example) whilst the control has a state of 'disabled'. Whilst this may seem reasonable, it does not hold true for other Tk widgets like Tk::Entry (which I would consider a basic widget).

The workaround is simple:

# enable the control for changing
$text->configure(-state => 'normal');
# do any changes
$text->insert('end', 'text');
# restore state
$text->configure(-state => 'disabled');
[download]

So, the wisdom I seek is, has anyone else noticed this, has it been fixed in a later version, who should I contact?

Comment on Possible bug in Tk::Text Download Code

Replies are listed 'Best First'.
Re: Possible bug in Tk::Text by converter (Priest) on Jun 09, 2003 at 20:06 UTC
The `Tk::Text` POD documents this behavior: `Name: state Class: State Switch: -state Specifies one of two states for the text: normal or disabl +ed. If the text is disabled then characters may not be inserted or + deleted and no insertion cursor will be displayed, even if the inpu +t focus is in the widget.` [download] While this may seem inconsistent when compared with the behavior of other widget classes, I've always assumed there was a good reason for it. If you want a Text widget that can't be modified, but that doesn't require toggling -state, you can always use `Tk::ROText`, which replaces the bindings that are normally used to modify the text with noops.	[reply] [d/l] [select]
Re: Re: Possible bug in Tk::Text by zakb (Pilgrim) on Jun 10, 2003 at 07:47 UTC
I'd missed that in the POD. However, the POD for Tk::Entry says exactly the same, word for word, but Entry allows the text to be changed programmatically no matter what the state. The key difference is between what the user is allowed to do (which is what state controls) and what the programmer is allowed to do. Tk::ROText won't work for me, I need the text to be read/write for the user, just not all the time.	[reply]
Re: Possible bug in Tk::Text by aquarium (Curate) on Jun 09, 2003 at 22:24 UTC
it's not realy a bug as such..just semantics that the writer has chosen for the behavior. i.e. it is reasonable to provide a guarantee to the programmer that when this widget is created and disabled, that it not change or be changed through keyboard entry or another program, being disabled. makes sense to me. on the other hand, and especially for more complicated widgets, it would be normally expected that their contents would be massaged ad-hoc throughout program execution, to routinely format the output etc.	[reply]
Re: Re: Possible bug in Tk::Text by zakb (Pilgrim) on Jun 10, 2003 at 07:49 UTC
I agree 'bug' may be a little harsh, however, the behaviour is different to Tk::Entry, and as the two do a related job - a text field - this should be documented at the very least. I would consider Tk::Text to be considerably more complex than Tk::Entry!	[reply]


more useful options
	PerlMonks