Mouse wheel only works on first console in split window

[sejjiin]

When splitting consoles, mouse wheel scrolling only works reliably on the first console. On console 2 and 3, it rarely works. I haven't been able to pin down what triggers it to start working, but when it does, it only works briefly. I'm using 150707 [64] on Windows 8.1.

I have the below Task set up as the default task for new consoles.

>cmd -cur_console:n

-cur_console:ns1T45Vd:%startupDir% cmd /k tail -f Log.log

cmd -cur_console:ns1T50Hd:%USERPROFILE%

[Maximus5]

I think the key is a focus, where the text cursor is blinking...

[sejjiin]

It is focusing on hover (and the cursor is blinking), but will not scroll whether I click on the console first or not. Console 1 will scroll by simply hovering over it and scrolling the mouse wheel.

[Maximus5]

Can you reproduce that with log files?
http://conemu.github.io/en/LogFiles.html

[SamHasler]

@sejjiin do you use KatMouse or some other "mouse follows focus" software? I was having issues with splits until I set KatMouse's classes tab as follows:

VirtualConsoleClass      Default
VirtualConsoleClassBack  Ignore

[sejjiin]

Thanks for the replies. I don't use KatMouse, but do use Synergy, which might be conflicting somehow? I'll see if I can reproduce with the Synergy service stopped and, if so, attach logs here.

[deltreey]

Here's the gist with logs

https://gist.github.com/deltreey/9a113bd40c8b217b7152

[erquhart]

I am now encountering this issue after upgrading to Windows 10. Using Windows 8.1 I never had an issue. I don't use KatMouse, Synergy or anything like them. Only the first split scrolls with mouse wheel - the others do not, regardless of focus. This is using the msysgit (Git for Windows 1.95.x) bash - other shells do not exhibit this behavior. The new version of Git for Windows (2.x) has way too many issues to make an upgrade worthwhile.

[Maximus5]

Problem confirmed on Win10.

[Maximus5]

Another Microsoft Bug!
https://msdn.microsoft.com/en-us/library/ms645617.aspx
LPARAM do not let you obtain screen coordinates anymore.

[Maximus5]

Build 150813c (preview)

[VictorOscar]

I'm seeing this in Build 151208 on Win8.1, but not on Win10. I also tried on Build 151224 with the same results. When testing on Win10, I'm going through Remote Desktop.

[Maximus5]

LogFiles reproducing the problem with full-screen screenshots to be sure where mouse cursor is located when you scroll the wheel. StatusBar must be visible on screenshots.

[CollinChaffin]

FYI, I have identified and will be reporting to that author that if you are using x-mouse style apps like "x-mouse button control" (and possibly other x-mouse background-style mouse enhancers), THAT in my case was the cause of what you are describing - only my 1st pane in any split config scrolled, even with the mouse options all enabled in conemu. Simply right-clicking the xbutton and disabling instantly allowed ALL panes in conemu to begin scrolling properly.

EDIT: I opened an issue with XBMC author here:

https://forums.highrez.co.uk/viewtopic.php?f=6&t=3885

And of note as I also stated there - this issue is the same whether the mouse events enabled in conemu or not, as well as whether the panes (any of them other than #1) are active or background.

[Maximus5]

Can you create LogFiles with screenshots? Mouse over first split and second split for example?

[CollinChaffin]

I can report for those using XBMC (and other x-mouse type mouse enhancers) - I have performed additional testing which has confirmed a fix:

Change the mouse message type to "WPF Scrolling Msg" as shown here:

Any other mouse message type he uses (#1-4) render successful results but the WPF, when adjusted to 3 lines as shown above - shows un-noticeable difference in usability from any other window, so I could find no down-side in simply creating a new application profile in XBMC for the Conemu app and window class to simply always switch to the WPF method and it is working great!