Attachment "bind.n.patch" to
ticket [523593ffff]
added by
jenglish
2003-08-07 03:01:20.
Index: bind.n
===================================================================
RCS file: /cvsroot/tktoolkit/tk/doc/bind.n,v
retrieving revision 1.7
diff -u -r1.7 bind.n
--- bind.n 30 Sep 2002 09:35:39 -0000 1.7
+++ bind.n 6 Aug 2003 19:54:12 -0000
@@ -210,6 +210,161 @@
value determines which direction your widget should scroll. Positive
values should scroll up and negative values should scroll down.
.VE
+
+.IP \fBKeyPress\fP
+.IP \fBKeyRelease\fP
+\fBKeyPress\fP and \fBKeyRelease\fP events are generated
+whenever a key is pressed or released. \fBKeyPress\fP and \fBKeyRelease\fP
+events are sent to the window which currently has the keyboard focus.
+
+.IP \fBButtonPress\fP
+.IP \fBButtonRelease\fP
+.IP \fBMotion\fP
+\fBButtonPress\fP and \fBButtonRelease\fP events
+are generated when the user presses or releases a mouse button.
+\fBMotion\fP events are generated whenever the pointer is moved.
+\fBButtonPress\fP, \fBButtonRelease\fP, and \fBMotion\fP events are
+normally sent to the window containing the pointer.
+.br
+When a mouse button is pressed, the window containing the pointer
+automatically obtains a temporary pointer grab.
+Subsequent \fBButtonPress\fP, \fBButtonRelease\fP, and \fBMotion\fP
+events will be sent to that window,
+regardless of which window contains the pointer,
+until all buttons have been released.
+
+
+.IP \fBConfigure\fP
+\fBConfigure\fP events are sent to a window whenever its
+size, position, or border width changes, and sometimes
+when it has changed position in the stacking order.
+
+.IP \fBMap\fP
+.IP \fBUnmap\fP
+\fBMap\fP and \fBUnmap\fP events are generated whenever the mapping
+state of a window changes.
+.br
+Windows are created in the unmapped state.
+Top-level windows become mapped when they transition to the
+\fBnormal\fP state, and are unmapped in the \fBwithdrawn\fP
+and \fBiconic\fP states.
+Other windows become mapped when they are placed under control
+of a geometry manager (for example \fBpack\fP or \fBgrid\fP).
+.br
+A window is \fIviewable\fP only if it and all of its ancestors are mapped.
+Note that geometry managers typically do not map their children until
+they have been mapped themselves, and unmap all children
+when they become unmapped; hence in Tk \fBMap\fP and \fBUnmap\fP
+events indicate whether or not a window is viewable.
+
+.IP \fBVisibility\fP
+A window is said to be \fIobscured\fP when another window
+above it in the stacking order fully or partially overlaps it.
+\fBVisibility\fP events are generated whenever a window's
+obscurity state changes; the \fIstate\fP field (\fB%s\fP)
+specifies the new state.
+
+.IP \fBExpose\fP
+\fBExpose\fP events are generated whenever all or part of a
+window should be redrawn (for example, when a window is
+first mapped or if it becomes unobscured).
+It is normally not necessary for client applications to
+handle \fBExpose\fP events, since Tk handles them internally.
+
+.IP \fBDestroy\fP
+A \fBDestroy\fP event is delivered to a window when
+it is destroyed.
+.br
+When the \fBDestroy\fP event is delivered
+to a widget, it is in a ``half-dead'' state: the widget still exists,
+but most operations on it will fail.
+
+.IP \fBFocusIn\fP
+.IP \fBFocusOut\fP
+\fBFocusIn\fP and \fBFocusOut\fP events are generated
+whenever the keyboard focus changes.
+A \fBFocusOut\fP event is sent to the old focus window,
+and a \fBFocusIn\fP event is sent to the new one.
+.br
+In addition,
+if the old and new focus windows do not share a common parent,
+``virtual crossing'' focus events are sent to the intermediate
+windows in the hierarchy.
+Thus a \fBFocusIn\fP event indicates
+that the target window or one of its descendants has acquired the focus,
+and a \fBFocusOut\fP event indicates that the focus
+has been changed to a window outside the target window's hierarchy.
+.br
+The keyboard focus may be changed explicitly by a call to \fBfocus\fP,
+or implicitly by the window manager.
+
+.IP \fBEnter\fP
+.IP \fBLeave\fP
+.br
+An \fBEnter\fP event is sent to a window when the pointer
+enters that window, and a \fBLeave\fP event is sent when
+the pointer leaves it.
+.br
+If there is a pointer grab in effect, \fBEnter\fP and \fBLeave\fP
+events are only delivered to the window owning the grab.
+.br
+In addition, when the pointer moves
+between two windows, \fBEnter\fP and \fBLeave\fP
+``virtual crossing'' events are sent to intermediate windows
+in the hierarchy in the same manner as for \fBFocusIn\fP and
+\fBFocusOut\fP events.
+
+.IP \fBProperty\fP
+\fBProperty\fP events are sent to a window whenever an X property
+belonging to that window is changed or deleted.
+\fBProperty\fP events are not normally delivered to Tk applications.
+.br
+Note that Tk provides no useful details for this event type.
+
+.IP \fBColormap\fP
+\fBColormap\fP events are generated whenever the colormap
+associated with a window has been changed, installed, or uninstalled.
+.br
+Widgets may be assigned a private colormap by
+specifying a \fB-colormap\fP option; the window manager
+is responsible for installing and uninstalling colormaps
+as necessary.
+.br
+Note that Tk provides no useful details for this event type.
+
+.\" Added in wm-enablers patch:
+.IP \fBMapRequest\fP
+.IP \fBCirculateRequest\fP
+.IP \fBResizeRequest\fP
+.IP \fBConfigureRequest\fP
+.IP \fBCreate\fP
+These events are not normally delivered to Tk applications.
+They are included for completeness, to make it possible to
+write X11 window managers in Tk.
+(These events are only delivered when a client has
+selected \fBSubstructureRedirectMask\fP on a window;
+the Tk core does not use this mask.)
+
+.IP \fBGravity\fP
+.IP \fBReparent\fP
+.IP \fBCirculate\fP
+\fBGravity\fP,
+and
+\fBReparent\fP
+are not normally delivered to Tk applications.
+They are included for completeness.
+.br
+A \fBCirculate\fP event indicates that the window has moved
+to the top or to the bottom of the stacking order as
+a result of a \fBXCirculateSubwindows\fP protocol request.
+Note that the stacking order may be changed for other reasons
+which do not generate a \fBCirculate\fP event, and that
+Tk does not use \fBXCirculateSubwindows()\fP internally.
+This event type is included only for completeness;
+there is no reliable way to track changes to a window's
+position in the stacking order.
+
+.SH "EVENT DETAILS"
.PP
The last part of a long event specification is \fIdetail\fR. In the
case of a \fBButtonPress\fR or \fBButtonRelease\fR event, it is the
@@ -526,7 +681,7 @@
(outside the context of any Tcl procedure).
.SH "SEE ALSO"
-bgerror, keysyms
+bgerror, keysyms, grab, focus, bindtags, event
.SH KEYWORDS
form, manual