I am trying to create a subclass of VScroll control and intercepting the WM_VSCROLL message to do some stuff. On msdn, and countless articles/forums, WM_VSCROLL is supposed to be 0x115, even in the windows header file that’s what it is. However waiting on 0x115 doesn’t bring anything. I realized it’s coming through as 0x2115 instead, even this article is using it as 0x2115. Any reason/explanation as to why it’s coming as 0x2115 instead? Is it because it’s a WinForms control?
Thanks
Yes, this is pretty standard in Windows GUI class libraries, Winforms is no exception. The native Windows control, ScrollBar in your case, send notifications to their parent. After all, they were designed to make their parent act on the notification, not themselves. Or in other words, you expect the parent window to scroll.
That however is not very compatible with the notion of a control class whose behavior you can modify by overriding its message handling and generation. Or for that matter the idea of events in .NET, anybody can subscribe to the Scroll event, not just the parent.
That buys a lot of goodness, but something must be done to get the WM_VSCROLL message from the parent back to the control. Which is what the Winforms plumbing takes care of. It sends the message back but alters the message number to indicate that it was a reflected message, not the original. It adds 0x2000. The value of the (fake) WM_REFLECT message in the Winforms source code.