| Shawn Kielty 2004-05-20, 3:31 am |
| Hi -- I am guessing that what you'd like to do is create two text
widgets - one disable and greyed out -- the other white, normal and
enabled - using the options database to set the options values. This
might help in answering your question about the syntax of the option add
subcommand. Otherwise it might just pose other questions.
If the text widget had a disabledfg and disablebg -- this would be this
would be easier.
The documentation for the option command (at least in my old
version) is a bit lacking -- because it doesn't talk about the classes
of the widget -- i.e. the syntax of the pattern or the default DB Names
and Classes.
If you were planning to have an application that had a few disabled text
widgets and you wanted to make them all look the same --
the "option add" is useful -- the syntax is -- {see docs also}:
option add pattern value ?priority?
The pattern is the tricky part -- and I am not really sure I can explain
it very well. -- the best bet is to read the commments in option.c and
draw a map of the tree sturctures defined there -- looking at the
option.test helps too.
In this case it's a wild card pattern involving different nodes in the
tree where I know that Text and Foreground are both database class
names. (please correct me if I am wrong).
example:
#
option add *Text*Background grey80 80
option add *Text*Foreground grey20 80
pack [text .a -state disabled]
# eof
I believe that the option add command has to occur before the text
command. And of course could be changed as needed.
#
option add *Text*Background white 80
option add *Text*Foreground black 80
pack [text .b -state disabled]
# eof
And it gets very interesting when the class can get inherited from the
toplevel -- my example is using a toplevel -- but it should also work
using two classes of frames with the -class option.
info patchlevel = 8.4a1
# example
console show
option clear
# disable the state of the Class Hello
option add *Hello*State disabled
# color differently Hello
option add *Hello*Background blue
# Define a toplevel with a class thats disabled
toplevel .ab -class Hello
# Make a blue disabled text widget
pack [text .ab.c ]
# One for defaults
toplevel .d -class other
# normal default
pack [text .d.c]
# disabled
toplevel .e -class Hello
pack [text .e.hello]
# unfortunately -- .e.hello configure -state normal -- won't change
# the color. Which is what would be *really* useful.
# eof
Honestly -- I think there must be another way -- and maybe someone with
a real solid understanding of the options db can help -- but this seems
an idea to the problem of creating different text widget
characteristics in the same app. It seems to me that I might be able to
define nodes in the tree like Class.State.color and Class.State.state
resulting in a case where changing the state might also change the
color, but I just don't quite understand how the DB works. I'd enjoy
hearing any opinions about how this might be done more effieciently.
Some things come to mind -- like having -disabledfg and -disabledbg as
options to the text widget. So that they might be manipulated in a way
that is more familiar.
I hope this is helpful
Shawn
Cameron Laird wrote:
> In article <_o4oc.9164$bB3.8691@newssvr23.news.prodigy.com>,
> Bryan Oakley <bryan@bitmover.com> wrote:
>
text in[color=darkred]
>
>
> Is the question really about how to make a read-only text
> widget, OR how to disable a text widget, OR ...?
|