From: MSEdit on 23 Mar 2010 18:14 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 24 Mar 2010 06:15 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 24 Mar 2010 05:36 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 24 Mar 2010 08:59 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 24 Mar 2010 10:20 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
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Extension needs another DLL Next: C-level command for [file join [file dirname [info script]] |