| Message |
I am inclined to agree with David, that an app which is not active should not receive human-interface events, like keyboard presses, mouse clicks, or mouse-wheel movement.
Whilst I have two monitors here, they are on a Mac running XP under Parallels, which in their wisdom declines to implement dual-monitor support, so it is hard to test.
However a test I did where, under XP and a single monitor, if I have Crimson Editor open, and a MUSHclient window to one side, if I move the mouse so the pointer is over the MUSHclient window, but the Crimson Editor window is active, then scroll the mouse-wheel, the Crimson Editor window scrolls, not the MUSHclient one, which is for me the expected behaviour.
This test indicates to me that the OS is not trying to send mouse wheel movements to the app the mouse happens to be over, whether or not it is active.
Perhaps try to get an updated video driver, or updated mouse driver? It seems to me that somewhere someone is mistranslating the coordinates from the mouse pointer, not taking into account that it is over a different montor. However from MUSHclient's point of view, it is receiving mouse wheel movement over its application area, and is responding.
Tell you what, though. There is a test in the code that if the pointer happens to be over the command window, to scroll that. Otherwise, as a default, it scrolls the upper window. Perhaps that test should be tightened up to test if the mouse is indeed over the upper window. You could try to see if the problem occurs if you put the mouse over where the command window would be, if it was on the other monitor.
However a further test with MUSHclient shows that, if you put the mouse over the gray frame window (that is, outside a world window) and scroll the wheel, the window does not scroll - so that seems to suggest that it is indeed checking that the mouse wheel movements are directed to the correct window.
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | top |
|