Mouse focus lost

[7s3b]

There is no layer 12/13 log, but mouse focus lost again, here's the log file.

log_20251230.txt

[7s3b]

Issue came up again today, but there have been no errors since the last time.

[phil]

Im sorry it has taken me so long to look at these logs...
Ive had a look this morning, but unfortunately there is nothing obvious in those logs indicating a problem.

XMBC is seeing the button messages (down (press)/ up (release)), and passing them through without modification, so right now, I don't understand how the buttons are not working - it kind'a points to something outside of XMBC, I mean, if XMBC was seeing the buttons and not passing them through (unmodified) that would make more sense, but the log is indicating that the messages are being left, untouched... (Passing original mouse message 0x0000020x through....)

Im at a bit of a loss on this one

[phil]

Aha,,, I may have stumbled on a potential cause...
The logging it not too helpful, because it only keeps the last 200 messages in memory before you enable debug logging, and I suspect that is not enough to get the full picture here (I will increase it to keep 1000 messages for the next beta which will give more info).

However, one of those two log files above does indicate a potential problem...
You are using button chording with a default (no chord action).... This could be where to focus...

And it seems, there is one lockup, after you initiate a chord (with button 4) and then release button 4...
XMBC seems to be getting itself in a sticky situation - in that it blocks the button 4 DOWN message (as the chord is started) it then sees the button up, so released the chord, and simulates the button down message, but it lets the up through FIRST before the simulated DOWN... That's not good! as the button will then be stuck down (as the down got to Windows after the up)...

That may be the entire problem (or it could be unrelated - but I doubt it) - either way its highlighted an error in my logic... That I need to fix!

[phil]

Yes - I think that is it.
I manage to reproduce the problem here now (easy when you know how!).

It is because of your button chords. If you press the chord button and either don't release it quickly, or move the mouse, it automatically releases the chord, but in doing so, it injects the original button down message... the problem is, because that injected message happens in another thread, there is a chance that the button up message, caused when you release the button) may come too quickly (before the thread has sent the button down).

In that case, Windows actually sees the button UP before the button DOWN - and gets all confused - resulting in this problem.

I think the fix is simple. It seems to work here, but there may be some edge cases I haven't spotted.
I will build up Beta 58 and we can see how it goes. This must have been a problem for some time, and maybe explains a few of those unsolved weird stuck button issues.

EDIT: Please try Beta 58 and let me know how that goes!

[7s3b]

I'm so happy that you've finally found the solution to the problem. Thanks for taking the time to update the software, even with your busy schedule. I'm trying Beta 58 and will keep you updated.

[phil]

Let’s hope I really have found it - I hope so but time will tell! I think I may have been chasing this one for a while, and only now it became clear! If so, I will thank you very much! Fingers crossed this at least fixes your problem!

[7s3b]

It works fine so far:D

[phil]

Thanks for the update!