<TouchpadScroll>
Event Handlingscrollutil::addMouseWheelSupport
Commandscrollutil::createWheelEventBindings
Commandscrollutil::enableScrollingByWheel
Commandscrollutil::disableScrollingByWheel
Commandscrollutil::adaptWheelEventHandling
Commandscrollutil::setFocusCheckWindow
Commandscrollutil::focusCheckWindow
Commandscrollutil::addMouseWheelSupport
Commandscrollutil::addMouseWheelSupport
– Add mouse wheel
event supportscrollutil::addMouseWheelSupport tag ?axes?
<TouchpadScroll>
event
support to the widgets having the specified binding tag by creating
bindings for the mouse wheel and <TouchpadScroll>
events along the axes given by the optional axes
argument, which must be xy
(the default, meaning both the x
and y axes), x
(meaning the x axis only), or y
(meaning the y axis only). The binding scripts created by this
command will scroll the window given by the %W
event
field with the aid of the xview scroll number
units
and yview scroll number
units
subcommands of the associated Tcl command.tag
is the
path name of a window then the binding scripts created by this command are
terminated by an invocation of the break
command, in
order to prevent the processing of the mouse wheel or
<TouchpadScroll>
events by further binding
scripts. For example, if tag
is the path
name of a text widget then the terminating break
command makes sure that the mouse wheel or
<TouchpadScroll>
events will not
additionally be processed by the class bindings (associated with the
binding tag Text
), which in Tk 8.5 and later trigger a
scrolling by pixels, unlike the bindings created by this command,
which scroll the widget by units (i.e., lines and characters).<TouchpadScroll>
event support to the widget
class Canvas
or individual canvas widgets.<MouseWheel>
on
Windows, <MouseWheel>
and
<Option-MouseWheel>
on Mac OS X/11+, and
<MouseWheel>
,
<Button-4>
and
<Button-5>
on X11 (where
<MouseWheel>
is not triggered by the X
server, but can be produced using event
generate
).<Shift-MouseWheel>
on
Windows, <Shift-MouseWheel>
and
<Shift-Option-MouseWheel>
on Mac OS X/11+,
and <Shift-MouseWheel>
,
<Shift-Button-4>
and
<Shift-Button-5>
on X11 (where
<Shift-MouseWheel>
is not triggered by the X
server, but can be produced using event
generate
). On X11, when using Tk 8.7a3, there are two
more mouse wheel events along the horizontal axis:
<Button-6>
and
<Button-7>
, which are handled just like
<Shift-Button-4>
and
<Shift-Button-5>
, respectively. These
events are commonly triggered by left/right tilting the scroll wheel of
a mouse having one or two additional (thumb) buttons. (In Tk
versions 8.6.x, with x >= 10, left/right tilting the scroll wheel of
such a mouse gives rise to <Shift-MouseWheel>
events on Windows and Mac OS X/11+, and to
<Shift-Button-4>
and
<Shift-Button-5>
events on X11.)REMARK 4: In Tk versions 8.7a4 and later, the set of mouse wheel events is the same on all windowing systems:
<MouseWheel>
and
<Option-MouseWheel>
, where the
Option
modifier is bound to the Option
key on Mac OS X/11+ and to the Alt
key on Windows and
X11.<Shift-MouseWheel>
and
<Shift-Option-MouseWheel>
, where the
Option
modifier is bound to the Option
key on Mac OS X/11+ and to the Alt
key on Windows and
X11. In these Tk versions, left/right tilting the scroll wheel of
a mouse having one or two additional (thumb) buttons gives rise to
<Shift-MouseWheel>
(and
<Shift-Option-MouseWheel>
) events on all
windowing systems.scrollutil::createWheelEventBindings
Commandscrollutil::createWheelEventBindings
– Create mouse
wheel event bindingsscrollutil::createWheelEventBindings ?tag tag ...?
<TouchpadScroll>
event bindings for the specified binding tags such that if the widget under
the pointer is (a descendant of) one of the scrollable widget containers
having the same toplevel as the widget and registered via scrollutil::enableScrollingByWheel
then these
events will trigger a scrolling of that widget container. In case of
several nested registered scrollable widget containers fulfilling these
conditions the innermost one will be scrolled. Each
tag
argument must be all
or the
path name of an existing toplevel widget (including
.
).tag
arguments to all
and path names
of existing toplevel widgets rather than supporting also tags like
"Scrollableframe"
(for scrollutil::scrollableframe),
"BwScrollableFrame"
(for BWidget ScrollableFrame) or
"Scrolledframe"
(for iwidgets::scrolledframe) is that the
mouse wheel and <TouchpadScroll>
events should
trigger a scrolling of the widget container under the pointer not only if
the widget under the pointer is the widget container itself but also if it
is a descendant of the latter (recall that for each window, the path name
of its nearest toplevel ancestor and the tag all
are
contained in the window's default list of binding tags).scrollutil::enableScrollingByWheel
Commandscrollutil::enableScrollingByWheel
– Register
scrollable widget containers for scrolling by the mouse wheelscrollutil::enableScrollingByWheel ?scrollableWidgetContainer scrollableWidgetContainer ...?
<TouchpadScroll>
event bindings created by the
scrollutil::createWheelEventBindings
command.scrollutil::scrollableframe
command
automatically invokes this command for the scrollableframe widget it
creates.scrollutil::disableScrollingByWheel
Commandscrollutil::disableScrollingByWheel
– Deregister
scrollable widget containers for scrolling by the mouse wheelscrollutil::disableScrollingByWheel ?scrollableWidgetContainer scrollableWidgetContainer ...?
<TouchpadScroll>
event bindings created
by the scrollutil::createWheelEventBindings
command.scrollutil::adaptWheelEventHandling
Commandscrollutil::adaptWheelEventHandling
– Adapt mouse
wheel event handlingscrollutil::adaptWheelEventHandling ?-ignorefocus? ?widget widget ...?
-ignorefocus
switch is not
present then, for each widget
argument, the command
performs the following actions:widget
is the path name of a tablelist widget then it sets
the latter's -xmousewheelwindow
and
-ymousewheelwindow
options to the path name of
the containing toplevel window, provided that the Tablelist version
is 6.4 or later (for earlier Tablelist versions the command silently
ignores any tablelist widget passed to it as argument). As a
result, a mouse wheel or <TouchpadScroll>
event over the tablelist's body or edit window (more precisely, a
mouse wheel or <TouchpadScroll>
event sent
to any component of the tablelist having the binding tag
TablelistBody
or
TablelistEdit
) will be handled as follows:
event generate
. This in
turn will trigger a scrolling of the (innermost) widget container
that is an ancestor of widget
and has the same
toplevel (if there is such a scrollable widget container), provided
that the path name of the containing toplevel widget or the binding
tag all
was passed to the scrollutil::createWheelEventBindings
command and this widget container was registered for scrolling via
scrollutil::enableScrollingByWheel
.<TouchpadScroll>
event bindings and is different from both the path name of the
containing toplevel window and all
. If the
search for this tag was successful then the command modifies the
widget's list of binding tags by prepending the tag
WheeleventRedir
and appending the tag
WheeleventBreak
to this binding tag. As a
result, a mouse wheel or <TouchpadScroll>
event sent to this widget will be handled as follows:
[focusCheckWindow
widget]
then the event will be handled by the
binding script associated with this tag and no further processing
of the event will take place.[focusCheckWindow widget]
then the
event will be redirected to the containing toplevel window
via event generate
rather than
being handled by the binding script associated with the
above-mentioned tag. This in turn will trigger a scrolling of
the (innermost) widget container that is an ancestor of
widget
and has the same toplevel (if there is
such a scrollable widget container), provided that the path name of
the containing toplevel widget or the binding tag
all
was passed to the scrollutil::createWheelEventBindings
command and this widget container was registered for scrolling via
scrollutil::enableScrollingByWheel
.-ignorefocus
option is specified
then, for each widget
argument, the command performs
the following actions:widget
is the path name of a tablelist widget then it resets
the latter's -xmousewheelwindow
and
-ymousewheelwindow
options to ""
,
provided that the Tablelist version is 6.4 or later (for earlier
Tablelist versions the command silently ignores any tablelist widget
passed to it as argument). As a result, if the Tablelist version
is 6.16 or later, a mouse wheel or
<TouchpadScroll>
event over the tablelist's
body or edit window will scroll the tablelist or its edit window and no
further processing of the event will take place.<TouchpadScroll>
event
bindings and is different from both the path name of the containing
toplevel window and all
. If the search for
this tag was successful then the command modifies the widget's list of
binding tags by appending the tag WheeleventBreak
to this binding tag. As a result, a mouse wheel or
<TouchpadScroll>
event sent to this widget
will be handled by the binding script associated with this tag and no
further processing of the event will take place.<TouchpadScroll>
event bindings and are
descendants of a scrollable widget container. The Tk and tile widgets
having class bindings for mouse wheel and
<TouchpadScroll>
events are: listbox, text, Tk
core scrollbar, ttk::scrollbar, ttk::combobox, ttk::spinbox, ttk::notebook,
and ttk::treeview. Examples of widgets with binding tags other than
their class names that have mouse wheel and
<TouchpadScroll>
event bindings are ctext and
tablelist widgets, as well as the entry components of mentry widgets of type
"Date"
, "Time"
, "DateTime"
,
"IPAddr"
, and "IPv6Addr"
(for Mentry versions 3.2
and above). (In case of a ctext widget w
, the
binding tags mentioned in the description above refer to the widget's main
text widget child w.t
rather than to the widget
itself.)aqua
on the Macintosh. Scrollutil
eliminates this discrepancy by automatically creating the
Scrollbar
class bindings for mouse wheel events on
Windows and X11. Note also that in Tk versions prior to 8.7a4 the
ttk::scrollbar widget had no built-in class bindings for mouse wheel
events, but Scrollutil automatically creates the missing bindings by
copying the mouse wheel event bindings of the widget class
Scrollbar
to the binding tag
TScrollbar
.<TouchpadScroll>
events, hence this command
should be invoked for them in case they are descendants of a scrollable
widget container. Since this task can become tedious, Scrollutil
makes sure that if you pass a widget to this command and that widget is
embedded into a scrollarea via the latter's
setwidget
subcommand, then this command will automatically be invoked for the
scrollbars of that scrollarea, too.-ignorefocus
option, when handling a mouse wheel or
<TouchpadScroll>
event sent to a Tk core or tile
scrollbar whose path name was passed to this command, if the focus is on or
inside the associated widget then the event will be processed by the
scrollbar rather than being redirected to the containing toplevel, just as
if the focus were on the scrollbar itself.<TouchpadScroll>
event
bindings and are descendants of a scrollable widget container is essential
for a user-friendly mouse wheel and
<TouchpadScroll>
event handling in scrollable
widget containers. Without this step the mouse wheel and
<TouchpadScroll>
events would scroll both the
listbox, text, ttk::treeview, or tablelist widget under the pointer
and the widget container to whose descendants the latter belongs, or
they would select the next/previous value in the ttk::combobox or
ttk::spinbox under the pointer in addition to scrolling the widget
container.-ignorefocus
option, because it
significantly reduces the probability that the user will inadvertently
scroll a window within a widget container containing many scrollable
widgets.scrollutil::setFocusCheckWindow
Commandscrollutil::setFocusCheckWindow
– Set the "focus
check window"scrollutil::setFocusCheckWindow widget ?widget ...? otherWidget
widget
argument, the command sets the
associated "focus check window" to otherWidget
.
This is the window to be used in the binding scripts for the tag
WheeleventRedir
instead of the
widget when checking whether the focus is on/inside or outside that
window. For each widget
argument,
otherWidget
must be an ancestor of or identical to
widget
.widget
arguments
gets destroyed, the association between the widget and its "focus check
window" is automatically removed.WheeleventRedir
less restrictive. For
example, if the widget under the pointer is an entry component of a
mentry me
of type "Date"
, "Time"
, "DateTime"
,
"IPAddr"
, or "IPv6Addr"
and the focus is on any
of its siblings, then the mouse wheel and
<TouchpadScroll>
events sent to this entry should
be handled by the entry widget itself rather than scrolling the widget
container that is an ascendant of the mentry. You can achieve this by
invoking
set entryList [$me entries]
eval scrollutil::adaptWheelEventHandling $entryList
eval scrollutil::setFocusCheckWindow $entryList [list $me]
set entryList [$me entries]
scrollutil::adaptWheelEventHandling {*}$entryList
scrollutil::setFocusCheckWindow {*}$entryList $me
ss
is a scrollsync
widget that was populated via its setwidgets
subcommand with
child widgets. Then, if the widget under the pointer is one of these
children and the focus is on any of the other children passed to that
subcommand, then the mouse wheel and
<TouchpadScroll>
events sent to the child under
the pointer should be handled by that child widget itself rather than
scrolling the widget container that is an ascendant of the
scrollsync. You can achieve this with the following code:
set widgetList [$ss widgets]
eval scrollutil::adaptWheelEventHandling $widgetList
eval scrollutil::setFocusCheckWindow $widgetList [list $ss]
set widgetList [$ss widgets]
scrollutil::adaptWheelEventHandling {*}$widgetList
scrollutil::setFocusCheckWindow {*}$widgetList $ss
scrollutil::focusCheckWindow
Commandscrollutil::focusCheckWindow
– Query the "focus
check window"scrollutil::focusCheckWindow widget
widget
argument. This is the window that is used
in the binding scripts for the tag WheeleventRedir
instead of the widget when checking
whether the focus is on/inside or outside that window. If the command
scrollutil::setFocusCheckWindow
was not
invoked for widget
then the return value is
widget
itself.