Scrollbars are stealing the WM_MOUSEWHEEL message

[Harold Hunt]

Robert,

> -----Original Message-----
> From: Robert Collins [mailto:robert.collins@syncretize.net]
> Sent: Saturday, July 20, 2002 7:27 PM
> To: Harold Hunt
> Cc: cygx
> Subject: Re: Scrollbars are stealing the WM_MOUSEWHEEL message
>
>
> On Sun, 2002-07-21 at 09:23, Harold Hunt wrote:
> > I just discovered a problem with using scrollbars in Cygwin/XFree86:
>
> Interesting. I'd have thought that the WM_MOUSEWHEEL message still hit
> your main window message loop before the scroll bars loop? I presume
> that is not the case?

Here is the bottom of XWin.log after shrinking the Cygwin/XFree86 window and
doing about 20 downward mouse wheel scrolls:
Rules = "xfree86" Model = "pc101" Layout = "us" Variant = "(null)" Options =
"(null)"
winWindowProc - WM_SIZE - window w: 1023 h: 766, new client area w: 1015 h:
739
winWindowProc - WM_SIZE - window w: 1023 h: 766, new client area w: 1015 h:
723
winWindowProc - WM_SIZE - window w: 1023 h: 766, new client area w: 999 h:
723
winWindowProc - WM_SIZE - window w: 990 h: 743, new client area w: 966 h:
700
winWindowProc - WM_SIZE - window w: 913 h: 710, new client area w: 889 h:
667
winWindowProc - WM_SIZE - window w: 862 h: 686, new client area w: 838 h:
643
winWindowProc - WM_SIZE - window w: 844 h: 676, new client area w: 820 h:
633
winWindowProc - WM_SIZE - window w: 825 h: 664, new client area w: 801 h:
621
winWindowProc - WM_SIZE - window w: 822 h: 661, new client area w: 798 h:
618
winWindowProc - WM_MOUSEWHEEL


As you can see, we get one WM_MOUSEWHEEL message and then the scrollbar
takes them over.

The MS Platform SDK says that you are supposed to return 0 if we processes
this message in a parent window, while an OLE control is supposed to return
TRUE if it processes WM_MOUSEWHEEL.  So, I even tried changing the return to
TRUE and that made no difference.

In case anyone looks at the code and says, "oh, I see that in this one case
you are ``break''ing", yes, I tried changing that break to both ``return 0''
and ``return TRUE'' with the same behavior resulting.

Furthermore, I even just now changed all the ``return'' statements to
``break'' instead, on the hunch that the Platform SDK was wrong.  The
behavior was the same as before.

Harold