Community
Participate
Working Groups
Created attachment 111619 [details] Revisted snippet that respects mouse wheel on Windows This is exhibited by the current snippet: http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet296.java?view=co Attached is a fix to that Snippet to make it work on Windows. On Linux/GTK the scrolling works correctly with the unmodified original snippet.
This might be related to bug 93472
Hmmm ... this might be a WONTFIX. From memory, on Windows, controls need to have focus before they respect the mouse wheel.
Ok, I think the snippet should not be changed. Mouse wheel should go to the tree, not the scrolled composite. *** This bug has been marked as a duplicate of bug 93472 ***
(In reply to comment #3) > Ok, I think the snippet should not be changed. Mouse wheel should go to the > tree, not the scrolled composite. > > *** This bug has been marked as a duplicate of bug 93472 *** > The whole point of this is that the Tree is not supposed to scroll (I can't use the Tree's (native) scrolling behavior because it's missing the ability for me to directly scroll it programmatically where I want, so I'm using NO_SCROLL on the tree an doing the scrolling in the ScrolledComposite.) So I don't want the Tree to handle the mouse wheel.
Steve, I didn't test this problem but given the description I'd say it is similar to Bug 244664. What happens is that SysTreeView32's winproc always(1) consumes WM_MOUSEWHEEL, so the parent never gets message. Bug 244664 is the same case, but it uses a multiline text instead of a Tree. Should we detect when WM_MOUSEWHEEL doesn't scroll the control and call defwindowproc ourselves ?
I think that this is the right (but unwanted) behavior. Mouse wheel goes to the focus widget on Windows. The focus widget is a buttton. Buttons don't do anything with mouse wheel. Am I missing something? I thought that mouse wheel was inherited. Please show me the code etc. and let's get to the bottom of it.
Sorry, didn't see the NO_SCROLL (I was reading my email backwards). Yes, if the tree doesn't have scroll bars and cannot scroll, then we should forward the event. Does the table do this?
>Am I missing something? >>Yes, if the tree doesn't have scroll bars and cannot scroll, then we should >>forward the event. There, that is the behaviour. But I think we can be more specific about the 'cannot scroll' part. Here the cases: a) Control doesn't have scrollbars - SWT.V_SCROLL and/or SWT.H_SCROLL are not set - SWT.NO_SCROLL is set ACTION => FORWARD EVENT TO PARENT NOTE: does SWT.NO_SCROLL work everywhere (in all controls) ? b) Control has scrollbars but it is disabled (maximum > pagesize) c) Control has scrollbars and the thumb is showing, but it is scrolled all the way to an end (selection=minimum OR selection==maximum) ------- Two options that I would be okay with: 1. Implemented (a) and (b) and (c) to behave the same. 2. Make sure (a) works, and let the behaviour of (b) and (c) to be platform specific.
Created attachment 122753 [details] patch Steve, if you are okay with this fix we can do the same for Text.
I noticed the patch on this, any chance we can get this in 3.6?
(In reply to comment #10) > I noticed the patch on this, any chance we can get this in 3.6? Hi Francis, I think first we should decide the proper behaviour for the platform (see comment 8) and fix it on all controls (Text/Table/Tree/etc). Right now we are busy finishing items that are in the 3.6 plan, if time allows I plan on fixing this bug (and all others in this area). I'll do my best.
Created attachment 156660 [details] Original Snippet296 that shows the problem The Snippet246 in CVS was revised (version 1.6) to hide the problem and is now incorrect as it causes double scrolling on Linux/GTK. It should work the same on all platforms. If you try this version on GTK and move your scroll wheel one notch it will move only one item as it should, applying the "fixed" version it will move two items. This problem also exists on OSX Cocoa (scrolling does not work with this snippet, but does work correctly when the mousewheel listener is added). Not sure about Carbon.
See bug 300205 that complains about the revision to Snippet296 (Snippet246 reference in above comment is typo - should be 296). See also bug 300204 that is the same problem on OSX Cocoa
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug is still there in Eclipse 2021-09 on Windows 10. Steps to reproduce (directly in the IDE). - on an empty IDE create a dummy Plugin Project - Switch to the PDE Perspective - Show the Properties View - select the dummy project in the Project Explorer -> the Properties View should show the project properties in a tabbed properties view - make sure the Properties View is small enough vertically to not show the complete contents - while hovering over either the horizontal or the vertical scroll bar try to scroll with the mouse wheel -> works as expected - while hovering over the Properties TreeTable try to scroll with the mouse wheel -> does not work
