Community
Participate
Working Groups
Most (sadly, not all) Windows applications allow the user to scroll a view using the mouse wheel even if a different view currently has the focus for keyboard events. It is frustrating when you want to scroll, say, the Package Explorer but because the source editor currently has the focus it scrolls instead - even if the mouse is positioned over the Package Explorer. In order to scroll the Package Explorer you have to click somewhere in it to give it focus, and if like me you have Link With Editor turned on, this can mean accidentally opening another file - when all you wanted to do was scroll down a bit! I don't know if some users prefer it this way or not - if so perhaps it could be an option somewhere.
The native win32 behaviour is to scroll the focus window, not the hovered window; applications that don't behave like this are overriding the native behaviour. For swt to override the native behaviour while its mandate is to preserve native behaviour would be wrong. However, I believe that most mice with scrollwheels can be configured to behave as you describe, such that scroll events are natively delivered to the hovered window instead of the focus window, which would make swt behave accordingly for you. The configuration involves installing your mouse's custom driver and configuring its setup (Start -> Settings -> Control Panel -> Mouse).
First, I'm not talking about scrolling a *window* that doesn't have focus - just a *view* within the main window. The main window would have focus. Second, I couldn't find anything in the control panel to allow scrolling out-of- focus windows/sub-windows. I can't remember ever seeing such an option. Third, SWT preserving native behaviour? Please! How about the editor/view tabs in Eclipse? How about the editor/view min/max/restore buttons? The perspective switcher? The toolbars? The pop-up outline window? None of these resembles anything I've ever seen in Windows (although I should point out I think they're all far superior to the standard widgets in Windows). Fourth, Windows does actually do what I'm talking about - for example, the standard Windows Explorer window will scroll either the folders tree on the left or the main part of the window with a wheel mouse regardless of which side has focus. Internet Explorer will scroll any frame you have your mouse over without having to click it to get focus. FireFox too. Same goes for Outlook's preview pane. Actually, just poking around the applications installed on my computer right now, I can't find many examples of Windows apps with multiple sub-windows/frames that *don't* let you scroll without specifically setting focus first. It seems to be standard behaviour.
>> Third, SWT preserving native behaviour? Please! ... These are custom controls that are used to brand Eclipse and have no requirement to be native. They are subject to change at the whim of the designers of Eclipse, not SWT. >> Fourth, Windows does actually do what I'm talking about ... GG to verify this behavior and also confirm that there is a mouse setting on the control panel that we should be looking at.
*** Bug 69342 has been marked as a duplicate of this bug. ***
*** Bug 56715 has been marked as a duplicate of this bug. ***
*** Bug 20647 has been marked as a duplicate of this bug. ***
From Bug 56715 "Additional Comment #3 From Stefan Zeiger 2004-05-28 09:37 ------- On Windows, the mouse wheel behaviour has changed between IntelliMouse 4.x and 5.0. With 4.x, the widget under the mouse pointer was scrolled, with 5.0 the focused widget is scrolled. On my system, I see this change in all applications, including Eclipse. (There are more annoying "features" in 5.0: It lacks application-specific mouse button bindings and the support for high- resolution mouse wheels makes scrolling in combo boxes highly unpractical.) Unfortunately, 4.x doesn't support tilt wheels and doesn't make use of the higher resolution of new IntelliMouse wheels, so I upgraded to 5.0. In all other regards, I liked 4.1 much better. "
from MSDN: "WM_MOUSEWHEEL The WM_MOUSEWHEEL message is sent to the focus window when the mouse wheel is rotated. The DefWindowProc function propagates the message to the window's parent. There should be no internal forwarding of the message, since DefWindowProc propagates it up the parent chain until it finds a window that processes it."
Hey guys, I feel you've started throwing pies here ;-) You're arguing if theory (docs) or practice (major apps) should be followed, and that could be a long argument... Looking at the history of win32, and how "obsolete" it is compared to today's way of thinking (most of the GUI related stuff in win32 dates all the way back to Windows 1.0), I think the important thing is not any longer what the win32 documentation dictates but instead what major applications do. I think you have all seen how MS themselves constantly change the Windows platform (note: not the win32 interface) by putting new and hot features hardlinked into new applications or supplied as component dlls. F ex the standard win32 pushbutton is abandoned by Windows XP itself. With this perspective it isn't really important to investigate a specific mouse setting for the mouse wheel behaviour, as the major applications mentioned (f ex Outlook 2003) exhibit their chosen behaviour independently of this setting on a plain Windows install. So, I must agree with the original poster that the mouse wheel should scroll the view containing the mouse pointer. It is also quite natural, if you think about it, that mouse operations affect the control where the mouse pointer is located and keyboard operations (entering text) affect the control containing the text cursor. You wouldn't expect a right mouse button click in one control to actually bring up the context menu of another control owning the keyboard focus, right? The mouse wheel is analogous.
Looking at the number of bugs that have been marked as a duplicate of this one, and a quick search for "mouse wheel" (perhaps other search strings would yield more) shows that this is a very popular request. Eclipse users want this fixed. Ref: bug 71176 bug 30466 bug 46646 bug 58656 bug 45355 bug 49816 bug 20647 bug 50895 bug 69342 Obviously nobody wants to compromise the integrity/consistency of the Eclipse platform, and adherence to OS conventions is very important. But it would appear that despite the win32 API the current Windows convention is that the mouse wheel operates on the component it's in, while the keyboard operates on the component that has focus. I'm not a win32 expert, but couldn't the mouse wheel event be allowed to bubble up to the application window level, where the current mouse position is used to determine which component to scroll? If so, I wouldn't think that any "rules" had been broken. Any win32 experts out there care to enlighten us?
*** Bug 103658 has been marked as a duplicate of this bug. ***
Could it be, that the reason for people not being able to agree on this issue is that you dev guys writing the SWT win32 platform code want "your" win32 api to resemble the original as closely as possible, which makes perfect sense, while the user guys want Eclipse to exhibit standard application behaviour, which also makes perfect sense? To make everybody happy I guess the code to correct the mouse wheel behaviour could go into the Eclipse code, so SWT is kept "pure". But most people writing their own SWT app would want to reuse this piece of code, so it would be an advantage if it was packaged into something easy to plug in or put as a partial layer on top of SWT event handling.
*** Bug 114409 has been marked as a duplicate of this bug. ***
Isn't it odd for something to stay as new for something like 17 months. I bought a new car and a house in that time span and I do not consider any of them as still new... :) Besides kidding, can someone make a decision on this, so that we can decide on wether we must implement this on our owns? I had also reported a bug on this issue and I do not even see it here as a duplicate. I am sure there is at least a dozen in the stack of other bugs related or the same issue as this one but not marked as duplicate of this one.
NEW in bugzilla terms just means the issue is open.
Billy, I provide bugzilla communications for my clients in my own comapny as well. So I am well aware of what NEW means. My point is why it is stated as NEW (or open) for 17 months without a fixed or temporary resolutin (not solution). I think for an issue, 17 months is too long. There should be a resolution like later, won't fix so a large number of people watching this bug - actively or passively - can decide what to do based on this input. What if I start to implement and just before the night I release it, I see this enhancement made its way into eclipse? I would really feel bad. On the other hand, what if I choose to wait on this cluelessly till someone makes an input and if another 17 months pass.... So with all the respect to your work schedule a positive / negative or negative for X Time would be highly appreciated. I am not and blaming anyone nor in the position to do this. I just would like to take my position. With bugzilla terms just whining.... Hope now my previous comment makes more sense. Regards, H.Ceylan
Regarding comment #16, I think Hasan has a point. If you click on the "Status" link in bugzilla you get this page: https://bugs.eclipse.org/bugs/page.cgi?id=fields.html#status which says (formatting added for clarity): "NEW This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be: a) accepted (and become ASSIGNED), b) passed on to someone else (and remain NEW), c) or resolved (and marked RESOLVED)." Although it doesn't explicitly say so, I think the intention for (b) was that if it were passed on to someone else then the algorithm would loop (i.e., counted as "recently added to the new assignee's list of bugs"), and therefore bugs wouldn't remain in the NEW state for long. Sorry for the OT meta-discussion, but if that's not how the field should be used then the fields doc should be changed to clarify the point. Although it's a splitting-hairs kind of thing, this is one of those edge conditions where it's important to agree on the same rules and definitions because we have such a large and diverse community.
A small addition: Focus is on view A mouse is over view B Hasan has his gancy LG mouse - Rolling mouse wheel scrolls the A vertically - pushing the scroll button to left or right (Horizantal - seek) scrolls B horizontaly So probably SWT is overriding the native behaviour somewhere down the layers... Hasan
I hoped being able to workaround this issue using the Control#setCapture() API, but somehow it did not work as expected. See Bug 148094. Ben
Here is part of the solution, working with 3.3 M6. It still requires the widget to have focus, but allows to scroll the widget that the mouse is currently hovering over: public class Main { public static void main(String[] args) { final Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); Table t = new Table(shell, SWT.None); for (int i = 0; i < 100; i++) { new TableItem(t, SWT.None).setText("Hello World"); } t = new Table(shell, SWT.None); for (int i = 0; i < 100; i++) { new TableItem(t, SWT.None).setText("Hello World"); } display.addFilter(SWT.MouseWheel, new Listener() { public void handleEvent(final Event event) { final Control cursorControl = display.getCursorControl(); if (!cursorControl.isFocusControl() && cursorControl instanceof Scrollable) { /* Break Condition */ cursorControl.setFocus(); /* Re-Post Event to Cursor Control */ event.doit = false; event.widget = cursorControl; display.post(event); } } }); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } } }
Upgrading to IntelliMouse 6.1 makes no difference.
Created attachment 63769 [details] Plugin to enable focusless scrolling FYI I wrote a small plugin that will change mousewheel-scrolling to scroll the control that is under the mouse-pointer. Just drop it into an eclipse installation. It works best with Eclipse >= 3.3 M6 I give no warranty about any side-effects (havent had any yet though). Use at your own risk :-)
Excellent Benjamin! Thanks.
Is this bug fixed in 3.3? Whatever view or editor the mouse is over does scroll without needing to change focus first. I am on Linux. Maybe it appears fixed because Linux SWT allows this and Windows SWT doesn't? If so, then shouldn't this bug be closed and a more specific bug be opened?
The bug is still there on Windows. I think the reason why it works for you is because SWT follows what the underlying SDK does. On Windows mouse-scroll events are dispatched to the focused control instead of to the control containing the mouse-pointer, but apparently the SDK used in your Linux distro does it the expected way. Today many applications "correct" this behaviour in their own code, but SWT doesn't.
Just my 2 cents of wisdom: Why do we still bother? I am using Benjamin Pasero's plugin essentially since he supplied it and it works perfectly (BTW: thanks a lot, Benjamin!). I suggest, to make this plugin better known and available (not everybody would expect utilities like this to be downloadable from some Bugzilla entry...). IMHO it should actually be integrated into SWT (so also other apps can benefit from it). Then provide some option in the eclipse pref's to switch it on/off and then we could finally tick this issue as solved. Michael
(In reply to comment #22) > Created an attachment (id=63769) [details] > Plugin to enable focusless scrolling > > FYI I wrote a small plugin that will change mousewheel-scrolling to scroll the > control that is under the mouse-pointer. Just drop it into an eclipse > installation. It works best with Eclipse >= 3.3 M6 > > I give no warranty about any side-effects (havent had any yet though). Use at > your own risk :-) > Any chance you can post another version of the JAR that includes the source under EPL?
Sorry, unfortunately the original source has long gone from my workspace.
Created attachment 90888 [details] Scrolling manager to enable focusless mouse wheel scrolling
Hello Benjamin, I have tired your code but it still not work as expected (still need me to focus on something focusable in order to scroll) I have attached a util class which fix this problem (only tried on Windows) Then in the View class, add this to createPartControl(), display.addFilter(SWT.MouseWheel, new Listener() { public void handleEvent(final Event event) { ScrollManager.getInstance().registerScrollable( display.getCursorControl()); } }); The result is all ScrolledComposite in the application will got scroll when the mouse inside it. However I still figure out how to make a ui.startup plugin like your to make it easier to use. Next step would be make it scroll for all Scrollable (List, Text .. etc) Hope this helps
Hello Guys, how about this (no side effects): final ScrolledComposite sc = new ScrolledComposite(parent, SWT.V_SCROLL | SWT.H_SCROLL); sc.setLayout(new GridLayout(1, false)); sc.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true, 1, 1)); Composite scrolledContent = new Composite(sc, SWT.NONE); scrolledContent.setLayout(new GridLayout(1, false)); scrolledContent.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true)); sc.addMouseListener(new MouseListener() { @Override public void mouseDoubleClick(MouseEvent e) { } @Override public void mouseDown(MouseEvent e) { sc.forceFocus(); } @Override public void mouseUp(MouseEvent e) { } }); Point size = scrolledContent.computeSize(SWT.DEFAULT, SWT.DEFAULT); scrolledContent.setSize(size); sc.setContent(scrolledContent); It works fine in my case: if a click inside the scrollable's content occurs, the composite takes the focus and scrolls on mouse wheel.
(In reply to comment #31) Remark: the MouseListener has to be added to: 1) the ScrolledComposite (as shown in the code above) 2) all its Composite children (the code was not pasted) Of course it's not the prettiest workaround.
Weird I am still using this plugin and it works fine for me. To make your plugin activate on startup you can use the extension point "org.eclipse.ui.startup". Ben
*** Bug 58656 has been marked as a duplicate of this bug. ***
*** Bug 257006 has been marked as a duplicate of this bug. ***
I just started to use an old Logitech mouse on WinXP today, and the inability to scroll inactive widgets drove me crazy (not only in Eclipse). With a little googling, I found this little gem called "WizMouse", which fixes this bug in all applications. It really saved my day: http://antibody-software.com/web/software/software/wizmouse-makes-your-mouse-wheel-work-on-the-window-under-the-mouse/
After 4.5 years and no status change on this bug report I wonder what the SWT folks' thoughts are? Do you consider it correct that Eclipse/SWT scrolls the focused view (and not the hovered view) when using the scroll wheel? If not, how can this bug be addressed before many more years have passed?
*** Bug 266195 has been marked as a duplicate of this bug. ***
I have a growing number of users reporting this behavior as a bug, which lead me investigating and finding this bug report. I will try to find a temporary solution, but I want to express my view that I too find it counter intuitive that a component that is not under the mouse gets scrolled. All Windows applications that I use have the expected component-under-the-mouse behavior. Severity should be changed from "enhancement" to "bug".
(In reply to comment #39) > I will try to find a temporary solution, but I want to express my view that I > too find it counter intuitive that a component that is not under the mouse gets > scrolled. I too agree that this is counter-intuitive. However... > All Windows applications that I use have the expected > component-under-the-mouse behavior. ...I just tried this with Notepad focused over Firefox 3.6, IE 7, and Windows Explorer, they all scroll Notepad even though my mouse is over the other window. I even tried a GTK+ application and it scrolled Notepad. I am using Windows 7. Unfortunately, I don't have any "high-profile" Microsoft applications (such as Office, Outlook, or Visual Studio) to try.
(In reply to comment #40) > ...I just tried this with Notepad focused over Firefox 3.6, IE 7, and Windows > Explorer, they all scroll Notepad even though my mouse is over the other > window. This is very interesting, because the behavior is not consistent depending on the systems. I have 2 systems. Windows XP #1: described behavior, non-focused control in a focused eclipse does not scroll (this very annoying bug). Windows XP #2: non-focused control in a non-focused eclipse does scroll (yeah!) There seems to be 3 cases depending on your drivers and so on: - Only focused control can scroll (bah). - Non-focused control can scroll if window is focused (good). - Non-focused control can scroll even in non-focused windows (excellent). The second option is what need: it would definitely resolve this issue and remove a lot of frustration. The 3rd option is something that is nice to have but which I doubt SWT can do anything about.
As annoying as it is, this is really a problem in some Windows mouse drivers, and not restricted to SWT. Have you tried "WizMouse" (comment 36)? That solves the problem in all applications, no only SWT-based ones.
I can only chime in: install WizMouse and forget this issue (in all apps and in all Windows versions). It also works in apps, that do not support scroll wheels (by simulating scrollbar events). In fact, you don't even notice the difference any more between apps. I did and I'm a happy camper since... Michael
I ended up installing KatMouse (seems similar to WizMouse) to avoid going insane, however it does not completely solve the problem. The compare view (eg. used in CVS and SVN comparisons) does not scroll with the mouse wheel. You have to drag the scroll bar.
(In reply to comment #44) That can happen if a driver tries to be too smart and sends click events to the scroll buttons rather that sending real scroll events to the widget. In WizMouse, the following option needs to be disabled to make it work well: [ ] Enable mouse wheel for applications without mouse wheel support
No, this bug has nothing to do with mouse drivers, although there seem to be some drivers and utilites that help working around the problem. If you want to fix the problem just for yourself, then get one of those. If you want to fix the problem for any Eclipse user on Windows, so that Eclipse's behaviour will match that of "high-profile" (in Remy's words ;-) applications, then changes to the Eclipse or SWT codebases are needed. Alternatively, I guess Eclipse could bundle third-party mouse drivers or utilities to fix the problem :-P. It all boils down to the Windows low-level WM_MOUSEWHEEL event which is sent to the focused, and not the hovered, element. See http://msdn.microsoft.com/en-us/library/ms645617(VS.85).aspx Since the invention of this message API, the usability desires have shifted to prefer to scroll the hovered element. All high-profile applications one way or the other contain code to reroute the WM_MOUSEWHEEL message to the new target, and Eclipse will have to do the same to solve this problem. (In other areas of the OS you can usually find places without rerouting - f ex Windows Explorer and the standard File Open dialog in XP.)
*** Bug 318837 has been marked as a duplicate of this bug. ***
Created attachment 228900 [details] EasyScroll - class for mouse wheel scrolling without manual focusing
Happy Birthday bug 75766! With 15 years you probably reached puberty now. Here's my late birthday gift for you: display.addFilter(SWT.MouseVerticalWheel, e -> { Control cursorControl = display.getCursorControl(); if (cursorControl != null && cursorControl != e.widget && e.widget instanceof Control) { Control control = (Control)e.widget; Point displayPoint = control.toDisplay(e.x, e.y); Point cursorControlPoint = cursorControl.toControl(displayPoint); e.doit = false; Event event = new Event(); event.detail = e.detail; event.count = e.count; event.x = cursorControlPoint.x; event.y = cursorControlPoint.y; cursorControl.notifyListeners(SWT.MouseVerticalWheel, event); } }); Unfortunately I can't get it to work with Canvas controls.
