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,  fol-
       lowed 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 But-
       ton 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


KEYWORDS
