Home > Archive > Tcl > October 2006 > A thought for Tk: -mywidgettype option?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
A thought for Tk: -mywidgettype option?
|
|
|
| Every once in a while, I find it'd be handy to know what type of widget
$w is, without going to the effort of keeping track of it. It would be
handy to be able to have something like this available:
% grid [button .b -text "Hello world."]
% grid [radiobutton .r -text "Option 1."]
% foreach w [list .b .r] { puts [$w configure -mywidgettype] }
button
radiobutton
The main use I'd have is if I'm changing widget states from a list of
them, I could fairly easily do different things for different types
of widgets, just using a switch command.
It'd be trivial to code. Just return the widget type on the presence
of that -mywidgettype option.
Good idea? Bad idea? Info already available by other means?
Any better option name suggestions than -mywidgettype?
| |
| Eric Hassold 2006-10-30, 7:32 pm |
| > Good idea? Bad idea? Info already available by other means?
Hello,
Already there, see "winfo class" man:
% button .w1
..w1
% radiobutton .w2
..w2
% winfo class .w1
Button
% winfo class .w2
Radiobutton
Eric
| |
| Robert Heller 2006-10-30, 7:32 pm |
| At Wed, 25 Oct 2006 01:11:00 +0200 Eric Hassold <hassold@evolane.fr> wrote:
>
>
> Hello,
>
> Already there, see "winfo class" man:
>
> % button .w1
> .w1
> % radiobutton .w2
> .w2
> % winfo class .w1
> Button
> % winfo class .w2
> Radiobutton
*Except* some widget types (eg frame and toplevel) can have any class (both
take a -class option. This is probably not a real problem though, since
presumably, the programmer coded in a known value for the -class option.
The class of . is created from the name of the main script. Eg [info
script] and [winfo class .] will return related results (there is a
direct mapping from one to the other).
But for common widget types, winfo class does return the "widget type",
although that is not exactly the intent -- the 'class' of a widget is
actually used for looking up values in the option database.
>
> Eric
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
heller@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
| |
| Andreas Leitgeb 2006-10-30, 7:32 pm |
| Eric Hassold <hassold@evolane.fr> wrote:
> Hello,
> Already there, see "winfo class" man:
> % button .w1
> .w1
> % radiobutton .w2
> .w2
> % winfo class .w1
> Button
> % winfo class .w2
> Radiobutton
Almost, but not quite entirely ...
That will give odd results for "." (namely the name of the script)
and generally for frames and toplevels that have been passed a
"-class" option on creation.
| |
| Eric Hassold 2006-10-30, 7:32 pm |
| Andreas Leitgeb wrote :
>
> Almost, but not quite entirely ...
>
> That will give odd results for "." (namely the name of the script)
> and generally for frames and toplevels that have been passed a
> "-class" option on creation.
>
Right, but IMHO that's close enough to be usable in context described by
OP, without having to introduce a new "-mywidgettype" option, or "winfo
type $w" subcommand in Tk core.
BTW, toplevels (incuding .) can still be identified by comparing $w with
[winfo toplevel $w], no matter what their class actually is. And if a
frame is created with an explicit class name, chances are this is some
kind of me(g|t)awidget, and inferring the "widget type" from the widget
class is from my point of view not so bad.
Eric
|
|
|
|
|