Basically, my advice is in the discussion in comments to the question.
macika123 wrote:
Finally, it's working :D . I'm so happy.
After a bit research it seems, that I'm not alone with this problem. Synaptics' virtual scrolling feature is not working in some applications, but in my case the horizontal scrolling is working in Visual Studio (thanks for the tip to dig deeper in touchpad properties, where I found, that I can actually turn horizontal scrolling on).
When I'm listening for messages sent to my WPF application window using Interop, weirdly I receive WM_MOUSEWHEEL messages, even if I'm using virtual scrolling. However, the MouseWheel event still doesn't fire. Fortunately the HIWORD part of wParam is set correctly (at least for my purposes), so I can step zooming in and out based on wheel spin direction.
Now I'm just wondering, that what's this caused by? Basically, the application gets the message, but somehow it's lost in .NET.
Thanks for help and for reassuring, that my code and the error is somewhere else.
You are welcome.
Let me put some speculations here. I hope we are about to close this issue, because further steps can be out of our reach.
According to your description, your code does nothing by handling the mouse wheel event (next time, better show where you add the event handler to the invocation tree of some event instance, that is, corresponding += operator, because the method name
customTileController_MouseWheel
, strictly speaking, does not tell anything about it; also, never use such auto-generated names, they violate good Microsoft naming conventions, for some apparent reasons). It cannot be wrong.
First of all, all input events available in .NET are of different levels. Some are primary and are generated by the hardware and are pushed to the system through the hardware interrupts one some IRQ line and handled by the hardware driver, and some are secondary. For example, hardware events produce
KeyDown
and
KeyUp
events (also indirectly), but not
KeyPress
event, which is secondary to the first two; it comes into play after a long chain taking into account input language, to produce a character which does not exist on lower level.
This is not what happens to physical mouse wheel. When you roll it, hardware generates the event of the same level as, say, mouse move, even though in mouse move of an optical mouse, optical image recognition takes place. Anyway,
from the computer standpoint, these are the events of the same level. The roll of the mouse cannot be misinterpreted as mouse move.
What happens in the touchpad "scroll" area? Nothing like that. Instead, some code is
just "trying" to emulate the same effect as the "real mouse" does. Physically, the primary events are still the same as you have with the regular touch. Note that even the mouse button down event can be "real" (touchpad has physical buttons, usually) or emulated, through the quick touch and them move. I don't really know where this simulation happens, in some piece of firmware or the driver, but I would rather guess it happens in the driver, that's it, at the expense of the computer's CPU. Some elements of "IA" are involved: recognition of the touch.
And we all know that the recognition can give you false positives and false negatives. And if the quality of the combination of the hardware (including firmware) and the driver is questionable, or some part of it is out of tune, the recognition results can be inadequate. Unfortunately, I failed to explain different results for different software; but it could be timing, the level of CPU load at the moment, anything which tends to confuse low-quality firmware or software… :-) I don't really know consistent experimental results to tell anything more certainly.
—SA