NAME

       bindtags - Determine which bindings apply to a window, and order of evaluation

SYNOPSIS

       bindtags window ?tagList?
_________________________________________________________________

DESCRIPTION

       When a binding is created with the bind command, it is associated either with a particular
       window such as .a.b.c, a class name such as Button, the keyword all, or any other  string.
       All  of  these forms are called binding tags.  Each window contains a list of binding tags
       that determine how events are processed for the window.  When an event occurs in a window,
       it  is  applied  to  each  of the window's tags in order:  for each tag, the most specific
       binding that matches the given tag and event is executed.  See the bind command  for  more
       information on the matching process.

       By  default,  each  window has four binding tags consisting of the name of the window, the
       window's class name, the name of the window's nearest toplevel ancestor, and all, in  that
       order.   Toplevel  windows have only three tags by default, since the toplevel name is the
       same as that of the window.  The bindtags command allows the binding tags for a window  to
       be read and modified.

       If  bindtags  is  invoked with only one argument, then the current set of binding tags for
       window is returned as a list.  If the tagList argument is specified to bindtags,  then  it
       must  be  a proper list; the tags for window are changed to the elements of the list.  The
       elements of tagList may be arbitrary strings;  however, any tag starting  with  a  dot  is
       treated as the name of a window;  if no window by that name exists at the time an event is
       processed, then the tag is ignored for that event.  The order of the elements  in  tagList
       determines  the  order  in  which binding scripts are executed in response to events.  For
       example, the command
              bindtags .b {all . Button .b}
       reverses the order in which binding scripts will be evaluated for a  button  named  .b  so
       that  all  bindings  are  invoked  first,  following  by bindings for .b's toplevel (“.”),
       followed by class bindings, followed by bindings for .b.  If tagList is an empty list then
       the binding tags for window are returned to the default state described above.

       The  bindtags  command  may  be  used to introduce arbitrary additional binding tags for a
       window, or to remove standard tags.  For example, the command
              bindtags .b {.b TrickyButton . all}
       replaces the Button tag for .b with TrickyButton.  This  means  that  the  default  widget
       bindings  for  buttons,  which are associated with the Button tag, will no longer apply to
       .b, but any bindings associated with TrickyButton (perhaps some new button behavior)  will
       apply.

EXAMPLE

       If  you  have a set of nested frame widgets and you want events sent to a button widget to
       also be delivered to all the widgets up to the  current  toplevel  (in  contrast  to  Tk's
       default behavior, where events are not delivered to those intermediate windows) to make it
       easier to have accelerators that are only active for part of a window,  you  could  use  a
       helper procedure like this to help set things up:
              proc setupBindtagsForTreeDelivery {widget} {
                  set tags [list $widget [winfo class $widget]]
                  set w $widget
                  set t [winfo toplevel $w]
                  while {$w ne $t} {
                      set w [winfo parent $w]
                      lappend tags $w
                  }
                  lappend tags all
                  bindtags $widget $tags
              }

SEE ALSO

       bind(3tk)

KEYWORDS

       binding, event, tag