What version ?

All og the scrollwheel forms work for me
roll - up/down
alt-roll - left/right
ctrl-roll - zoom in/out

v1.9.1; German skin; non of the scrollwheel combinations you mention works. Just a small scroll mouse icon appears - no action.
Its on a HP nx6325 laptop with (usual) SynTPEnh.exe translating the scroll area (lines on right side) in the mouse pad. In very other app this "wheel" works - including MS Excel Viewer (on the same Gnumeric files saved as .xls)

Please try the latest build,  I doubt it makes a difference but it has the latest version of gtk.

This problem is unlikely to be gnumeric specific, it sounds like a lack of interaction between your SynTPEnh and gtk.  I'll forward this over the Tor to see if he has any insight into how to debug this.

> In [e]very other app this "wheel" works

And with every other mouse model, the scrollwheel works. So, using a similar generalisation as you did, I have proved that it is (the drivers for) your hardware that is broken.

Is there any easy way to debug what win32 events or messages are delivered, so I might start to debug why GTK doesn't like this emulated mouse wheel?

Since all other Windows programs work fine with it, one can presume that they don't need some kind of special event handling - or if they do.. GDK doesn't have it.

> Is there any easy way to debug what win32 events or messages are delivered

Yes. Set the environment variable GDK_DEBUG to a set of flags separated with colons to specify what classes of debugging output to get printed to stdout. "events" generates lots of debugging output related to the handling ot Windows messages and the GDK events generated based on them. This debug output is most useful if you cross-reference to the source code, of course.

Is this relevant:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2060815&SiteID=1

"Also, some laptops have crummy touchpad drivers (like my Synaptics) that
emulate a mouse scroll by sending WM_VSCROLL instead of WM_MOUSESCROLL."

That sounds relevant yes. The gdk/win32 code doesn't handle WM_VSCROLL or WM_HSCROLL messages at all. In fact, this is the first time I've heard of them;) Thanks. I will add support for them.

So that I can see what messages are generated by the emulated mouse wheel, please try running with the libgdk-win32-2.0-0.dll from
  http://tml.pp.fi/gdk.dll.zip
with GDK_DEBUG set to events, grep the output for WM_HSCROLL or WM_VSCROLL, and send that to me.

Looks like the WM_{V,V}SCROLL might not be the cause in my case. See message log I'm about to attach. There are no WM_VSCROLL or WM_HSCROLL messages, but plenty of WM_MOUSEWHEEL ones. For some reason, I guess they don't look like those from a normal mouse.

Created attachment 123210 [details]
Message log from running with GDK_DEBUG=events

I instrumented the event handler for WM_MOUSEWHEEL, and so far, all I can tell is that for touch-pad originating events, the function is quitting out at gdk_win32_handle_table_lookup().

Appologies for the signed integers, but here is the instrumented output:

WM_MOUSEWHEEL
 lp:31851442 wp:7864320
At: (946, 486)
Got null new_window from gdk_win32_handle_table_lookup

And from a proper scroll-mouse:

WM_MOUSEWHEEL
 lp:31851442 wp:7864320
At: (946, 486)
Handled, phew!

NB: I was careful to make sure the pointer remained in the same position for both.

Since the lparam and wparam of the messages seem to be identical, I guess we must summise that something else is wrong.

Since the hwnd being retrieved is found with WindowFromPoint, and we certainly appear to be getting the same coordinates, I'd have expected we'd get the same hwnd, and everything would work.

However.. (and I'm not a Win32 programmer), the synaptics driver appears to be putting a little icon under the mouse when I start to virtual-scroll. This _does not_ happen when virtual-scrolling in Firefox on Windows, but _does_, on the console, and GTK applications. It looks as if the mouse-cursor is changed. If this were actually to be a window (rather than a mouse-cursor), is it possible that the WindowFromPoint then returns a hwnd which GDK doesn't know about?

Please let me know if there is any further poking, or instrumentation you want me to try.

 

Created attachment 123265 [details] [review]
Proposed patch (possible fix)

It would seem that there is some hidden window (or it is the scroll icon) getting in the way of WindowFromPoint.

The attached patch avoids using that function (which can return any window on the system), instead, it finds the root window for the message's specified hwnd (the WM_MOUSEWHEEL message is delivered to the focus window), then walks up to the desired child window under the point using a ChildWindowFromPoint calls.

Why is it necessary for GTK to re-direct the scroll event to the window under the cursor, rather than following the platform paradigm of delivering it to the focused window?

It appears (trying that), that GDK windows (in my app at least) don't take the focus for this message by cliking into them, as in some native apps. If you try to deliver the message to the GDK window assocated with the message's hwnd, it gets dropped on the floor after the propogate call returns 0.

Hi guys,

I just wanted to prod and see what the status of this bug was. There is a patch attached which works around the issue, I understand that it may be the wrong fix, but does it provide any insight as to how the problem might be solved?

I got the nasty feeling that this problem could manifest in other places where GDK uses similar code to find child windows to deliver messages to. Is this a bigger problem which will take a more knowlegable developer to fix (Tor?), or is there any feedback on my patch which I could take away and work on.

*** Bug 568767 has been marked as a duplicate of this bug. ***

Reopening as the question in comment #9 has been answered in comment #11.

Yes this little fancy SynTPEnh.exe scroll icon (window) was/is here too.
"Just a small scroll mouse icon appears - no action"
(this icon is not when scrolling with external mouse on the same laptop as I see now)

I'm not into GTK and its UI policy/style guide. But wxWindows (another platform independent TK which is more Windows rooted), which I'm programming myself, for example follows the platform and takes the hWnd from the WM_MOUSESROLL Message - thus the focused Window. This is good if for example you click/focus a thin slider or other thin window, and than roll it with mouse wheel - the mouse can wander off while rolling. 

However I also like the behavior of Mozilla (Seamonkey, Firefox) and of JAVA/AWT, which scroll always the Window under the mouse, even when not focused/clicked (but only when App active). I'd prefer latter behavior 70%:30% :-)
The need for extra click is often annoying (and e.g. alters a slider position or so), or the rolling of previously focused things (often not/hardly visible) away from the mouse may even be surprising to innocent Windows users.

Mozilla manages somehow to do away that SynTPEnh scroll icon, and avoid this problem here. Problems however are there when there is a non-focused special top-most window over the app window - e.g. a mag-glass application: then Mozilla will not scroll - buggy - seems to also use WindowFromPoint(). But JAVA/AWT will scroll even then, when such external "top-most-non-focus-window" is over the app. AWT does also not erase the SynTPEnh icon. So AWT is the only TK known to me so far which is fully/mostly consistent with that alternative behavior.

The patch of 2008-11-23 by Peter Clifton seems to try to do the same as AWT. 
The problem of ChildWindowFromPoint() in use is that it returns also hidden/disabled windows. It should perhaps be:
hwndc = ChildWindowFromPointEx (hwnd, point, WP_SKIPINVISIBLE|CWP_SKIPDISABLED|CWP_SKIPTRANSPARENT);
or RealChildWindowFromPoint()

*** Bug 480477 has been marked as a duplicate of this bug. ***

We have a hack in 2.24.8 that fixes this