From: MSEdit on
On Mar 23, 10:35 pm, drscr...(a)gmail.com wrote:
> On 3/23/2010 5:13 PM, Aric Bills wrote:
>
> > There are at least two ways to do it.  What exactly are you trying to
> > accomplish?  If you want to check for mouse-overs for a specific
> > widget, you can create bindings for that widget to<Enter>  and<Leave>
> > events.  If you want to know which widget is under the mouse pointer
> > at a particular time, you can use [winfo containing ...] in
> > conjunction with data from another binding such as<Motion>  or from
> > other [winfo] subcommands.
>
> I have two synchronized listboxes that are deeply embedded in a widget
> hierarchy but they display side to side.  I would like the user to be
> able to use their mouse wheels to scroll these without having to click
> on them, which changes the selections they have made already.
>
> I was hesitant to use Enter/Leave but if there is no other way, that is
> an option. I will look into [winfo containing] command.
>
> DrS

why not simply bind to the mousewheel events (<4> and <5> on linux).
Have a look here http://wiki.tcl.tk/3893 for some more info especially
about generating mouse wheel eventts for the current widget.
I add this to all my programs now, I find it frustrating to not juts
point and scroll or even worse scroll somewhere else
(Yes thats you Explorer).

Martyn
From: Arndt Roger Schneider on
drscrypt(a)gmail.com schrieb:

> On 3/23/2010 5:13 PM, Aric Bills wrote:
>
>> There are at least two ways to do it. What exactly are you trying to
>> accomplish? If you want to check for mouse-overs for a specific
>> widget, you can create bindings for that widget to<Enter> and<Leave>
>> events. If you want to know which widget is under the mouse pointer
>> at a particular time, you can use [winfo containing ...] in
>> conjunction with data from another binding such as<Motion> or from
>> other [winfo] subcommands.
>
>
>
> I have two synchronized listboxes that are deeply embedded in a widget
> hierarchy but they display side to side. I would like the user to be
> able to use their mouse wheels to scroll these without having to click
> on them, which changes the selections they have made already.
>
> I was hesitant to use Enter/Leave but if there is no other way, that
> is an option. I will look into [winfo containing] command.
>
>
> DrS
>
>
Just write separate procedures for yview, yscrollcommand,
ystartscrollcommand
and synchronize scrolling the listboxes inside these procedures.
The synchronization is then handled by --passed through-- the assoziated
scrollbar[s].

An example for this can be found inside the rtl_mlistbox source code,
albeit the scrolled listboxes are mostly siblings and there is only a
single scrollbar
for all listboxes --If you use multiple scrollbars, one for each
individual listbox,
then better use a lock to prevent circular scrollbar events.

-roger
From: Christian Gollwitzer on
MSEdit schrieb:
> why not simply bind to the mousewheel events (<4> and <5> on linux).
> Have a look here http://wiki.tcl.tk/3893 for some more info especially
> about generating mouse wheel eventts for the current widget.
> I add this to all my programs now, I find it frustrating to not juts
> point and scroll or even worse scroll somewhere else
> (Yes thats you Explorer).

Note there is a platform difference, which one shouldn't change IMHO in
order not to surprise the user. In Windows, the scroll wheel event goes
to the widget which has focus. So If you want to scroll, you must set
focus by clicking on that widget. On Mac OSX (and also on most window
managers in Unix, I believe), the scroll event goes to the widget over
which the mouse pointer is hovering. So it is possible to scroll a
window in the background without clicking it and bringing it to the
foreground. DrS seems to be on windows and wanting to achieve the
hover-and-scroll behaviour.

Christian
From: MSEdit on
On Mar 24, 10:36 am, Christian Gollwitzer <Christian.Gollwit...(a)uni-
bayreuth.de> wrote:

> Note there is a platform difference, which one shouldn't change IMHO in
> order not to surprise the user. In Windows, the scroll wheel event goes
> to the widget which has focus. So If you want to scroll, you must set
> focus by clicking on that widget. On Mac OSX (and also on most window
> managers in Unix, I believe), the scroll event goes to the widget over
> which the mouse pointer is hovering. So it is possible to scroll a
> window in the background without clicking it and bringing it to the
> foreground. DrS seems to be on windows and wanting to achieve the
> hover-and-scroll behaviour.
>
>         Christian

This is exactly what I was saying The code on the link allows hover
and scroll by sending scroll events to the pointed widget.
I work regularly on Three different platforms and find the windows
model of click then scroll alot slower so have modified all my code to
use this single model.
I even added this to my notebooks to scroll the tabs as per FireFox...

I also gain modifiers to increase scroll speed and if necessary
horizontal scroll.

Martyn
From: drscrypt on
On 3/24/2010 5:36 AM, Christian Gollwitzer wrote:
> Note there is a platform difference, which one shouldn't change IMHO in
> order not to surprise the user. In Windows, the scroll wheel event goes
> to the widget which has focus. So If you want to scroll, you must set
> focus by clicking on that widget. On Mac OSX (and also on most window
> managers in Unix, I believe), the scroll event goes to the widget over
> which the mouse pointer is hovering. So it is possible to scroll a
> window in the background without clicking it and bringing it to the
> foreground. DrS seems to be on windows and wanting to achieve the
> hover-and-scroll behaviour.


Thanks to everybody for their recommendation. I was looking for this
"hover-and-scroll" behavior.


DrS