Community
Participate
Working Groups
org.eclipse.swt.widgets.Control.WM_MOUSEWHEEL(int, int) is just calling OS.DefWindowProc (handle, OS.WM_MOUSEWHEEL, wParam, lParam); and the comment said * Feature in Windows. If the WM_MOUSEWHEEL is handled by * the control, it may not send WM_VSCROLL and WM_HSCROLL * messages. The fix is to intercept the WM_MOUSEWHEEL message * and call the DefWindowProc which will convert the message to * send the appropriate WM_HSCROLL or WM_VSCROLL message. But this is probably not true. On WindowsXP with OS's default mouse driver for Microsoft Wheel Mouse, all editors such as DefaultText Editor or Java Editor don't scroll by mouse wheel. If the Microsoft IntelliPoint driver(4.0) is installed, then they start working. IntelliPoint driver has additional functionality which enables mouse wheel to virtually all apprications. (You can turn on/off this feature from mouse properties ->wheel tab->Wheel Troubleshooter->Advanced button.) If the feature is turned off, then all eclipse editors don't work with mouse wheel. However, help viewer will work on such environment since it is actually InternetExplorer, and it directry supports WM_MOUSEWHEEL event. I guess SWT also need to handle the event directry.
I agree that we should handle it directly.
*** Bug 5501 has been marked as a duplicate of this bug. ***
On Linux, since the X protocol doesn't define wheel events, the usual solution is to have the server map wheel movement into button 4 and button 5 events. Most applications don't bind actions to these natively, so the usual next step is to provide a Translation Table resource that maps them to scroll actions, but SWT could support the buttons directly. For the full story, see http://koala.ilog.fr/colas/mouse-wheel-scroll/ Brian Thomson, IBM
Created attachment 180 [details] Proposed fix: patch to SWT.win32.org.eclipse.swt.widgets.Control.java
I'm using Eclipse on Win2k and was experiencing the same problem. After some research I came to the same conclusion Veronika did: WM_MOUSEWHEEL (int wParam, int lParam) call to OS.DefWindowProc does not handle events by default. I got the mouse wheel working by generating a WM_VSCROLL event from WM_MOUSEWHEEL after detecting that the event wasn't handled automatically. The proposed solution is attached. Although the mouse wheel does work, it scrolls only a single line at a time. The current rate is too slow to scroll through long files. Windows defaults the number of lines to scroll to 3.
Should also be fixed on the Motif/Linux distribution. Bernard
Created attachment 198 [details] Cleaner solution for handling mouse wheel events in Windows
A better way to handle WM_MOUSEWHEEL is to process them in the Scrollable class. The second patch does just that, replacing the first one. After digging through some windows documentation I found lots of information on how to handle WM_MOUSEWHEEL events. I tried to build all the documented rules into the code. It seems to be working very well. There is one workaround in the code though because I needed to make a system call that is not available in the current library. The code is using an overloaded version of OS.SystemParametersInfo but the new builds of the library should include the signature to support SPI_GETWHEELSCROLLLINES calls.
*** Bug 6986 has been marked as a duplicate of this bug. ***
*** Bug 5659 has been marked as a duplicate of this bug. ***
*** Bug 6973 has been marked as a duplicate of this bug. ***
Fixed in > 20020104 for Windows. The fix implemented is not the same as the fixed described by Mario. The implemented fix allows the native widgets to implement WM_MOUSEWHEEL in their own way and only provides a workaround for custom or emulated widgets. It handles horizontal and vertical scrolling and sends WM_VSCROLL and WM_HSCROLL messages. The fix is only for the Windows platform - I am still investigating the other windowing systems we support.
This report is marked as 1.0. One of the listed duplicate reports is for 2.0. What version is this fix targeted for?
This bug has been fixed in the 2.0 stream only.
This PR has been fixed on Windows for a while. Brian, if you feel that the support on Linux is insufficient, can you enter a new PR that describes the work you would like done on Linux?
