Dual screen + mouse scroll = issue

If I have a window in the left monitor active, and MUSHclient open on the right monitor, and I start mouse scrolling on the left window, it'll scroll that window normally but also scroll the output in MUSHclient (yet MUSHclient is not active). This shouldn't happen AFAIK.

[EDIT] Doesn't seem to always happen.

Isn't this a problem with Windows's handling of the mouse input, and not MUSHclient? That is: if MUSHclient isn't even active, how could it be handling the scroll messages?

Firefox + Pidgin doesn't have this problem. So far it only seems to be MUSHclient.

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.

I can confirm that Windows has behaved like this for at least as long as I started using Linux, and it's actually kind of infuriating to me... ;)