So, you have coded up a beautiful GUI, in which you have
programmatically created a lot of widgets.  While debugging
your script, you find out that you need to know which widget
is which?

----
======
proc which_widget {widgetname} {
        set res {}
        catch { set res [winfo class $widgetname ]}
        puts "$widgetname is a $res widget."
}

bind all <Enter> {which_widget %W}
======
----

Now all you have to do is place the mouse pointer
in the widget in question.

Hope this helps someone save a little time and effort.

''so September 8, 2001 ''

----

The problem with this, of course, is that I don't want debug code splattering huge amounts of text all over my control window while I'm debugging... so I do it slightly differently.
======
proc which_widget {widgetname} {
    set str "{[winfo class $widgetname]} $widgetname"
    wm title [winfo toplevel $widgetname] $str
}

bind all <Enter> {which_widget %W}
======
A Question for you, ''so''. Why do you do this:
======
catch { set res [winfo class $widgetname ]}
======
when this would make so much more sense?
======
catch {winfo class $widgetname} res
======
'''-EE'''

[RS]: The second way would put either the [winfo class] result, or the error message into ''res'', which maybe he didn't want to display in the window title - the first way is a "silent catch" (if you initialize ''res'' to an empty string before). An alternative would be
=======
if ![catch {winfo class $widgetname} res] {
    wm title ...$res ;# or puts ...$res
}
======
[SO]: EE, nice touch putting the info in the title.  Richard
addresses the "silent catch" issue, and (as usual) demonstrates
more elegant scripting style.  In practice, I personally
dont bind this to the enter event either, for the reason you
stated.  I figured people would modify things to suit their
own tastes and purposes. It just seems to make a better ''demo''
when bound to enter.

<<categories>> GUI