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