Community
Participate
Working Groups
Within a single SWT Canvas, I have several lightweight objects that resemble SWT Scrollables, but are not themselves widgets at all. If I scroll the scrollwheel, scroll events go to the canvas. I wish to intercept the events at the canvas, and redirect them to the lightweight objects based on either: a) they are under the mouse b) they have "focus", as defined in my lightweight focusing system. This appears to be technically possible, at least on windows. I have seen where the new JDK 1.4 supports scrollwheels on Swing components, which are identical to what I have in that they are lightweight objects on a single heavyweight OS window. The preferred implementation would be identical to Mouse events. I would add a ScrollListener to a Canvas (or Scrollable, in this level genericness can be supported). My ScrollListener would be notified of ScrollEvents when the OS sends scroll messages to the window for whatever reason (most likely a scrollwheel). If possible, the event should contain the x,y location, if not, I'll query it from the Display. Requirement: I need to be able to add such a listener (and have it notified) even without constructing a Canvas with SWT.H_SCROLL or V_SCROLL flags. It appears that Swing is able to do this on Windows. Run the Swingset2 demo on JDK 1.4. Go to the JList tab, and notice that scrollwheel works, and there doesn't **appear** to be any OS Controls with scrolling enabled.
On the ScrollEvent, if I set the doit field to false, I would like to "consume" the event, preventing the Scrollable from handling the scroll in the default manner.
To be considered post-R2.0.
This is pretty important to GEF. For example in the Palette, we have multiple drawers. The User may have 2 drawers open, and wish to use the scrollwheel to scroll through the available items. The entire palette is a single Canvas. It seems like a new ScrollWheelListener could be added and listeners notified in Scrollable.WM_MOUSEWHEEL(...). I would need to be able to consume the event, meaning don't forward the scroll to the scrollbar. I would need the mouse x,y location to process the ScrollWheelEvent. Also, is it possible to get this event even if the H/V_SCROLL style is not set? just wondering, because I don't need native scrollbars in the Palette anywhere. I suppose I could hide them, and just ignore them.
We should try and make this happen.
We need this to happen in 2.1.
Can this be priority 2?
Sorry Randy, we did not get to this. It's not clear that this can be done on Motif as there is no scroll wheel API in X. Needs more investigation.
We also require this capability for our application. Primarily for quick zoom in and out ability. In visualizations zooming is a common task so this is important. The fact that it is not supported on motif seems secondary because we should support it on windows, and on motif applications could do graceful degradation and use a menu or other approach. Does GTK support it?
The event need not be fired on Motif. Since even some Windows users don't have a Scrollwheel, there *will* be alternatives to the scrollwheel.
I am also in need of a fix. Does anyone have a workaround in the meantime? I could subclass the widget I wanted to capture the event from and implement windowProc on a stand alone SWT app (looking for OS.WM_MOUSEWHEEL) but this doesn't seem to work when I take the same widget and move it to an eclipse view.
I need this too. I need to zoom-in/out the contents of the canvas in my SWT app based on the mouse wheel. BTW, scroll wheels work on Windows AND Macintoshes (including OS X) ! That's 99.9% of the GUI market right there. --j
>>Does GTK support it? Yes.
Any news for 3.0?
*** Bug 47775 has been marked as a duplicate of this bug. ***
*** Bug 50404 has been marked as a duplicate of this bug. ***
*** Bug 73276 has been marked as a duplicate of this bug. ***
BTW, how does StyledText get scroll wheel events? Can anyone point me at the appropriate place in the source? (The Eclipse editors respect scroll wheel events, so it must be possible...)
Scrollable converts WM_MOUSEWHEEL messsages into WM_VSCROLL and WM_HSCROLL
Since my bug 73276 was merged with this,let me add here what wasn't a duplicate. We also need the ability to handle the extra mouse buttons, like the Forward/Back thumb buttons on many modern mice. This is particularly annoying in Eclipse itself, which has Forward/Backward actions but can't respond to the mouse buttons like all the web browsers do.
One alternative is to send a MouseDown event when any of button of 7-buttons mice is pressed. The button field should be filled according with: 1 - left button 2 - middle button 3 - right button 4 - wheel up 5 - wheel down 6 - back button 7 - forward button On Windows button 4 and 5 are sent via WM_MOUSEWHEEL, 6 and 7 via WM_XBUTTON. Inside Scrollable this OS message (WM_MOUSEWHEEL) is translate into a SWT.Selection event for the vertical scrollbar (if it exist), or for the horizontal scrollbar (if it exist). SWT does not listen for WM_XBUTTON. On Windows is not possible to implement MouseUp for buttons 4 and 5 (the wheel). On X, all the buttons of the mice generate a XButtonEvent, the button field of this structure already has the right number for us (4 for wheel up, etc). On motif, we can implement MouseDown and MouseUp for all the buttons. On GDK, if during a ButtonPress the button is 4, 5, 6, or 7 the XButtonEvent event is converted into GdkScrollEvent with the detail GDK_SCROLL_UP, GDK_SCROLL_DOWN, GDK_SCROLL_LEFT, GDK_SCROLL_RIGTH respectively. On GtkScrolledWindow the GdkScrollEvent is converted into value_changed signal, 4 and 5 change the vertical scrollbar, 6 and 7 change the horizontal scrollbar. The GdkScrollEvent is send to widget, so we could use them to simulate MouseDown, the problem would be how to do MouseUp for buttons 4,5,6, and 7 since GDK ate the events. I did not see what Carbon does.
So, when buttons 4,5,6 and 7 are pressed SWT will fire two events a MouseDown for the Control and a Selection for the ScrollBar (if exist). The problem are: (a) In some places we can't implement MouseUp, (b) These extra Mouse events can break existent code.
> SWT will fire two events... No. SWT needs to first fire the Scrollwheel event. Then, iff Event.doit is still TRUE after listeners have been notified, then the Scrollbar will be scrolled, and fire widgetSelected. If doit==FALSE, the scrollbar must not change. I agree that poorly written code will be problematic when MouseDown buttons 4-7 occur. Note that MouseUp is not guaranteed even for buttons 1-3. For example, if focus is lost, or with context menus or mouse dragging outside the control on Linux. MouseEvent API already mentions the possibility for additional buttons beyond 3: "2 for the second button, and 3 for the third button, etc." I think "etc." is pretty clear ;-) However, what will the statemask contain? SWT.BUTTON_4-7? The safest choice might be to add MouseNavigationEvent or MouseListener2, or something.
"I agree that poorly written code will be problematic when MouseDown buttons 4- 7 occur." Yes, Check the Tree widget in Motif, rotating the wheel cause the selection to change to the item under the cursor :-) You can test in the Package or Outline view. Not sure how to implement the mask, Windows does not provide mask for the wheel. X and GDK provide mask for BUTTON1 to BUTTON5.
Reassigning pr.
Fixed > 20041129 (not in this week integration) We added SWT.MouseWheel in Control. The fields in the event that are relevant are: detail - can be SCROLL_PAGE or SCROLL_LINE count - indicates how many lines or pages should be scrolled (can be negative) doit - set to false if, for example, the control also has scrollbar and the application don't want the scrollbar to move when the wheel rotates. We also added MouseDown and MouseUp for buttons 4 and 5 (plus mask for both buttons).
It sounds like only vertical scrollwheel events have been added. What about horizontal? Thinkpads have had 4-way scrolling for at least 5 years now. New mice have 4-way scrollwheels too.
We simply don't have the hardware to try it. Can you confirm that the native windows controls such as the tree respect wheel direction?
Every SWT Control with an enabled horizontal scrollbar will scroll horizontally just fine. Come one, Steve, you guys have to have a T2x, T30, or T40 somewhere in Ottawa. I would have a harder time getting a pencil down here :-). You hold the blue button in the middle. I don't really see us using the horizontal axis immediately, but if your going to add interfaces/constants and such you might want to do it all-at-once.
I agree. FH to find the hardware and check it out. Like I said, I don't have one and none of the desktop machines here have one either.
We have added support for one axis wheel only. The problem for adding 4-way wheel was not only hardware (cause that is easy to get), it was cause the only platform where the support for it was obvious is Mac OS. I looked in MSDN and I couldn't find how to do it for Windows (WM_MOUSEWHEEL is not the answer). In X and GTK it is much worse, to have one axis wheel working was hard (and hacky) enough.
How ironic, given that the Mac ships with the most incapable mouse of any PC sold in the last 20 years.
Here's an MSDN article which shows how to handle horizontal scrolling, both on Longhorn (with WM_MOUSEHWHEEL) and on 2000/XP (with IntelliMouse messages): http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/BestPracticesforSupportingMicrosoftMouseandKeyboardDevices.asp
Thanks for the article, interesting: "Currently, there is no operating system support for the tilt wheel. Microsoft IntelliType Pro or IntelliPoint software—for keyboards and mouse devices, respectively—must be installed to enable this functionality. With the software installed, horizontal scrolling works for many applications." ... "The upcoming Microsoft operating system, code-named "Longhorn," will implement the WM_MOUSEHWHEEL message to support tilt wheels."
If I understand this correctly, whenever the user uses the mouse wheel, SWT will fire a mouseDown event (with button == SWT.BUTTON4 or BUTTON5)? Is that right? I've written a simple snippet which launches an SWT control and prints out some text when the mouseDown event is fired. Nothing is printed out when I use the mouse wheel.
Nope. Look for SWT.MouseWheel.
Aaaah. Thanks, Steve. So, now what are SWT.BUTTON4 and SWT.BUTTON5 used for?
Nevermind. I figured it out.
The IBM trackpad does not generate the new scroll events. It doesn't actually simulate a scrollwheel, but sends WM_SCROLL events directly to the canvas. Here's partial stacktrace when the trackpad causes scrollbar to fire selection changed: FigureCanvas(Scrollable).wmScroll(ScrollBar, boolean, int, int, int, int) line: 389 FigureCanvas(Scrollable).WM_VSCROLL(int, int) line: 336 FigureCanvas(Control).windowProc(int, int, int, int) line: 3089 Display.windowProc(int, int, int, int) line: 3370 OS.PeekMessageW(MSG, int, int, int, int) line: not available [native method] OS.PeekMessage(MSG, int, int, int, int) line: 1994 Display.readAndDispatch() line: 2443 So is it possible to hook in at the WM_VSCROLL point and intercept the message and do something else with it? How can you tell it apart from when the user clicks on the scrollbar? Swing *does* work with the trackpad scrolling, but only vertically.
