mouse wheel capture

102 views
Skip to first unread message

Stefan Küng

unread,
Sep 24, 2016, 8:12:07 AM9/24/16
to scintilla-interest
On Windows, the mouse wheel messages go to the window that has the focus. But often, that's not the wanted behavior. On Windows 10 there's a setting which allows to change that behavior (Devices->Mouse and Trackpad->Scroll inactive windows when I hover over them).

Attached is a patch that allows Scintilla to be configured so that it only handles the wheel messages if the mouse pointer is over the editor and pass the message on if it's not.
That way, a client can handle that message and pass it on to other windows as required.

As an example, imagine a text editor using Scintilla, with the editor showing a tree view of project files on the side. If the user moves the mouse pointer over to the tree view and scrolls with the wheel, the scintilla window is scrolling because it has the focus. But what's really wanted is that the tree view scrolls.
With this patch, that's now possible.

The patch introduces new flags: SC_CAPTURE_NONE, SC_CAPTURE_MOUSE and SC_CAPTURE_WHEEL for the SCI_SETMOUSEDOWNCAPTURES command: instead of a bool, that command now uses these flags (OR-able). Since I didn't want to change the behavior as it is by default, the flag is now initialized as (SC_CAPTURE_MOUSE|SC_CAPTURE_WHEEL), meaning both the mouse and the wheel messages are captured.
To not capture the wheel messages, call SCI_SETMOUSEDOWNCAPTURES(SC_CAPTURE_MOUSE) or SCI_SETMOUSEDOWNCAPTURES(SC_CAPTURE_NONE).


wheel-capture.zip

Neil Hodgson

unread,
Sep 24, 2016, 9:40:21 PM9/24/16
to scintilla...@googlegroups.com
Stefan Küng:

> The patch introduces new flags: SC_CAPTURE_NONE, SC_CAPTURE_MOUSE and SC_CAPTURE_WHEEL for the SCI_SETMOUSEDOWNCAPTURES command: instead of a bool, that command now uses these flags (OR-able). Since I didn't want to change the behavior as it is by default, the flag is now initialized as (SC_CAPTURE_MOUSE|SC_CAPTURE_WHEEL), meaning both the mouse and the wheel messages are captured.
> To not capture the wheel messages, call SCI_SETMOUSEDOWNCAPTURES(SC_CAPTURE_MOUSE) or SCI_SETMOUSEDOWNCAPTURES(SC_CAPTURE_NONE).

Seems reasonable although it does change behaviour for clients that are currently calling SCI_SETMOUSEDOWNCAPTURES(0). Inverting SC_CAPTURE_WHEEL would, however, be ugly. May be cleaner to make this a new property.

Including a documentation patch would be useful. Explaining an API can help ensure it works sensibly.

Neil

gmis...@gmail.com

unread,
Sep 24, 2016, 11:28:36 PM9/24/16
to scintilla-interest, nyama...@me.com
Hi Neil

May I just add some supplementary context to this conversation because I'm a related party and it seems useful information for everyone to add here:

Here's what I think Stefans patch is about:

I submitted a patch for BowPad yesterday that lets the user use the mouse wheel to scroll the tab bar left and right. In my patch, I used a mouse hook to capture wheel events from any window that has the focus (in this case that window is usually scintilla) and then redirect the wheel events to a handler in the tab bar instead *iff* the mouse is over the tab bar at the time of the event.

This allows the tab bar to handle wheel events when it doesn't have the focus and do the tab scrolling *no matter what window has the focus, be it scintilla or any window*. I'm not aware of any significant downside or problem with my patch or the solution.

However, Stefan's patch - and I am guessing this is his reason for suggesting it - is that his patch would allow him to not use a mouse hook anymore and simply just have scintilla forward the message to bowpad and bowpad forward it to it's tab bar thus avoid a mouse hook altogether.

I did consider Stefan's solution myself but decided against it because conceptually at least Scintilla may not be the only window with the focus. For example, if the focus were in some other window (e.g. an edit control on the ribbon say, but I haven't tried this) then the tab bar would appear to not scroll any more.

So with this background what I'm explaining here is a) the use case I believe Stefan has in mind - if that helps you decide on the merit of his patch - but also b)  I'm also suggesting that for Stefan's use case his patch to you is arguably not necessary or even the right/best patch for BowPad, though it might work enough to be acceptable.

But the situation is arguable and Stefan's solution may work well enough that there is some reason to prefer his solution. But I just don't see that yet.

But even if my patch turns out to be the better solution for bowpad, it's not to say Stefan's patch is not also a worthy/handy addition to Scintilla anyway. i.e. It might well make sense for Scintilla to get Stefans patch AND bowpad to not use it as it turns out anyway, for instance.

Anyway, I hope this additional information helps you guys pick or evolve the best solution for both Scintilla and Bowpad.

Thanks
GM

Stefan Küng

unread,
Sep 25, 2016, 8:05:32 AM9/25/16
to scintilla-interest, nyama...@me.com

new patch attached:
* introduces two new commands SCI_SETMOUSEWHEELCAPTURES and SCI_GETMOUSEWHEELCAPTURES
* independent from SCI_SETMOUSEDOWNCAPTURES
* doc change included
wheelcapture2.zip

Neil Hodgson

unread,
Sep 26, 2016, 11:48:52 PM9/26/16
to scintilla...@googlegroups.com

Stefan Küng

unread,
Sep 27, 2016, 1:47:20 PM9/27/16
to scintilla-interest, nyama...@me.com

Thanks!

Stefan
Reply all
Reply to author
Forward
0 new messages