scrollutil::createWheelEventBindings
Commandscrollutil::enableScrollingByWheel
Commandscrollutil::adaptWheelEventHandling
Commandscrollutil::setFocusCheckWindow
Commandscrollutil::focusCheckWindow
Commandscrollutil::createWheelEventBindings
Commandscrollutil::createWheelEventBindings
– Create mouse
wheel event bindingsscrollutil::createWheelEventBindings ?tag tag ...?
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 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 (remember
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).<MouseWheel>
on Windows,
<MouseWheel>
and
<Option-MouseWheel>
on Mac OS X, 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
).
The mouse wheel events along the horizontal axis are
<Shift-MouseWheel>
on Windows,
<Shift-MouseWheel>
and
<Shift-Option-MouseWheel>
on Mac OS X, 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 or later, 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 Aqua, and to
<Shift-Button-4>
and
<Shift-Button-5>
events on X11.)scrollutil::enableScrollingByWheel
Commandscrollutil::enableScrollingByWheel
– Register
scrollable widget containers for scrolling by the mouse wheelscrollutil::enableScrollingByWheel ?scrollableWidgetContainer scrollableWidgetContainer ...?
scrollutil::createWheelEventBindings
command.scrollutil::adaptWheelEventHandling
Commandscrollutil::adaptWheelEventHandling
– Adapt mouse
wheel event handlingscrollutil::adaptWheelEventHandling ?widget widget ...?
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 event over the tablelist's body or edit window
(more precisely, a mouse wheel 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
.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 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
."Date"
, "Time"
, "DateTime"
,
"IPAddr"
, and "IPv6Addr"
(for Mentry versions 3.2
and above).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 events sent to this entry should be
handled by the mentry widget 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
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.