Cursor disappears when playing Simutrans

[BBGunn]

Hi all,

I have a slight problem that I'm wondering if anyone has a solution to.  Every time I play Simutrans on my Windows 8.1 computer at home, after several minutes, the mouse cursor will just disappear.  This only happens in the Simutrans window; if I move the cursor away from the Simutrans window to the desktop or another application, the cursor works just fine, but if I move it back to the Simutrans window, it disappears and I cannot use it for Simutrans.  When this happens, I have to save the game using the keyboard shortcut, then force the game closed.  When I restart it, the cursor will work fine in Simutrans again for several minutes, but then disappear again.  I never had this problem in Windows 7 or Windows Vista.

I said it's a slight problem because everything else in the game is working well, but it is enough of a problem to make me stop playing Simutrans.

Can anyone guess what's going on?  Do I need to install the SDL version of Simutrans, or GDI or whatever?  Would that help?

[An_dz]

I use the GDI version and this happens sometime, but I just click-'n-drag or right click-'n-drag and it shows up again. And this is on Win8.1 too.

[Ters]

Which version of Simutrans is this? The GDI cursor handling in looks correct in the sense that it should always show a cursor. (There is some dodgy code for showing the "hour glass" cursor during loading, but the problem should rather be that it reverts to the normal cursor.)

[BBGunn]

Sorry about the late reply, but I was away traveling for a few days.

The version is 120.0.1, r7373, which I believe is the latest version.

I played Simutrans again today, and it happened again.  It happens when I click-and-drag, for example, when I hold down the right mouse button and drag to scroll around the landscape.   However, I tried doing what An_dz said earlier in the thread that he does, which is click-and-drag again, and the cursor reappeared.

[An_dz]

The bug happens when the cursor "gets out" of the Simutrans window. From what I remember from the code when you release the mouse after a drag it resets the mouse position because while hidden it was technically moving around the screen.

[Ters]

Does anyone know if this happens with the GDI version, the SDL version, or both? If it's the GDI version, I can't really see how Simutrans could correct itself.

[BBGunn]

I'm using the GDI version, so it happens with that version on my computer.

[Ters]

From looking at the code, I can't see what could go wrong. I can see something that could go wrong if there is a bug somewhere, but it would cause the cursor to just become more and more hidden. (Unless the bug is so that it randomly or alternately forgets to either show the cursor or hide it, so that it cancels out over time.)

[prissi]

It just happens with Windows 7 or Windows 8.1 since a year ago or so. I suspect some update messed up the mouse driver. You can get this most likely by dragging the mouse out of the window quickly. Never happened with XP though. Not sure, how to fix this. And dragging again makes the mouse again visible.

[Ters]

If it happens with Windows 7 as well, I can give it a try.

Update:

With prissi's description, I was able to reproduce it. The problem is that when the mouse leaves the window, Windows no longer sends any messages about it, so Simutrans never gets any information that the mouse button is released. This means that Simutrans doesn't really know that the dragging is over, which is the cue for un-hiding the mouse cursor. (Simutrans keeps an internal state which avoids re-hiding the cursor on the next drag start event.)

I've uploaded a patch which according to https://msdn.microsoft.com/en-us/library/windows/desktop/gg153550(v=vs.85).aspx is the right way to keep getting information about an ongoing drag operation that leaves the confines of the Window. (In one of many attempts to get the cursor stuck hidden, it still did, but it was much, much harder with these changes.)

As for why it supposedly worked on Windows XP, I have no idea. Maybe a race condition between moving the cursor back inside the window, and Windows rejecting the window's "ownership" of the mouse?

[el_slapper]

in W8, I repair the thing by pushing my finger on the screen(yeah, I've got a touch screen). Not awful, as it's not common, but annoying.

[prissi]

I think the capturing had issues in old windows versions, when the second mouse button was pressed while the first was not released. But thank you, that does the trick mostly.

[An_dz]

You rock Ters. Had to be said.

[Ters]

I think the capturing had issues in old windows versions, when the second mouse button was pressed while the first was not released. But thank you, that does the trick mostly.

The example I linked to only dealt with one mouse button, so my patch does lack proper support for pressing a second mouse button during the capture. The mouse will be released when the first mouse button is released. There are some flags in the button up messages that might be used for holding off the release until all buttons are released. Handling messages for middle mouse button might be needed then. Or maybe we can just ditch the ReleaseCapture, the documentation is a bit vague on that.

[prissi]

I extended your patch with middle mouse button support already and committed it.

[Ters]

It might still release too early, since it doesn't check whether other buttons are still down when one is released.

You committed something else as well. Are those changes complete?

[prissi]

I hope so.