Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Possible bug in Tk::Text

by zakb (Pilgrim)
on Jun 09, 2003 at 14:57 UTC ( #264342=perlquestion: print w/replies, xml ) Need Help??

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

Hi

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');

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

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.

    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.

      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.

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.

      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!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://264342]
Approved by zby
Front-paged by tye
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2020-11-26 01:20 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?