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.