XMBC 2.21 Beta

[phil]

Toggling of while pressing the used key(s)/button(s) only remains. But if only single key was used it can be set to abort the toggle, so for most cases it will enough I guess.

Oh I think I may have missed that one - but I think it makes sense - I will have another look when I get a moment.

EDIT: No, I think its working as intended. If you choose to abort with ANY key, then any key will abort it (and toggle it off). If you choose to abort with a specific key that works. But yes, you cant choose more than ONE specific key. Thats as intended and if I need to change that, it wont be before 2.21 - But out of interest, whats the benefit of being able to choose multiple keys over a single one or over *any* key and/or any button? Persuade me why its desirable

For most cases it's fixed, but it still can happen after ok'ing some simkeys. Weird while on most it doesn't trigger it anymore. Like on one profile when ok'ing for 5th button didn't do it, but ok'ing on 4th button did. I'll attach the profile. If it will not be enough I'll send you others or log it later.

Again, I'll take a look and see if I can reproduce it with that profile. Previously (prior) to this change, it just checked the GUI elements to see if something had changed. Now it actually checks the settings objects that are saved into the file - so its a better check. Maybe I missed something though - hopefully the profile will help figure it out.

EDIT: OK there is a setting behind the scenes, that was added in 2.21 sometime, to store the keyboard layout used to enter the simkey. Your 4th button does not have that set (I guess because you havnt updated it since that background setting was added) that's why it is different. If you edit the 4th button on that profile, then apply it, it will then work as expected. I could "ignore" the hidden setting in the equality check but its probably not worth it in this case. It would be bettere to actually apply the change that it suggests is needed, then it wont happen again.

I'm sorry if I sounded pushy and ungrateful there, that wasn't my intention. I really appreciate that you still improve that awesome app, thanks.

Fair enough, I'm just glad I was able to find a little time to play with XMBC - its been too long. I really want to get 2.21 released (which will no doubt raise a load if issues not found in the beta - that's fairly normal, but with a bit of luck, having been tested for so long and by more than the normal amount of users, due to the time its taken I guess, there wont be anything seriously wrong!).

[maxoku]

But out of interest, whats the benefit of being able to choose multiple keys over a single one or over *any* key and/or any button? Persuade me why its desirable

Choosing to abort by any key/button means I can't play anymore, cuz anything I touch will toggle it off. Toggles are also for to play comfortably without need of holding specific keys/buttons when game demands it. Usually it's one key that needs to be held, but sometimes it's another mouse button (that can't be blocked and can be accidently pressed) or multiple keys that only together calls a specific action.

It would be bettere to actually apply the change that it suggests is needed, then it wont happen again.

That works indeed, thanks for looking into it.

[maxoku]

Unfortunately as I checked later the messed up windows aren't fixed, the bug still triggers. I don't know why I couldn't trigger it at all at that time. I've made you a clean debug log, so you wouldn't have to read too much.

XMouseButtonControl.log

[phil]

Well to be fair, that makes sense as I hadn't look at that at all (no changes around that).
I cant look at this today as away for a few days... I'll try and have a look later this week (but actually Im away for the next 3 weeks in a row :/ so it may take a little more time!)

EDIT: Unfortunately it looks like there is very little (useful) debug logging from that window chooser... I might have to add more debug logging first. Not entirely surprising as it has nothing to do with the main mouse hooking routines where most the debug logging is concentrated (and it hasn't really been touched for years)...

Quick question, are you using click and drag off the target icon to find the window, or hover mode (to select and freeze with capslock)?

[maxoku]

I didn't know you can click and drag. The bug happens only after using the hover mode.

[phil]

Ah OK that's useful info I think

OK - I think I found something - try Beta 57 for me and let me know.

[phil]

Here is 2.21 Beta 57

Changes since 2.21 Beta 56:

• #924 - Attempt to fix hover mode in the advanced window profile picker is breaking windows focus/activation.

Portable version:

XMouseButtonControl 2.21 Beta 57 Portable.zip

If you ever see the XMBC bug trap crash window popup (particularly for beta versions) asking you to report the crash, please do so (hit the send report button) and if possible, also contact me here on the forums, Discord or by email so I can try and get to the issue. Whilst the BugTrap logs do often help, they don't always give enough information to diagnose and fix the issue.

As usual, feedback welcome - especially if you find a bug! Any issues/problems, Enable debug logging, make a note of the time the problem occurs and then PM me a copy of the log file (or post a snippet of the last hundred lines or so in a code block here).

NOTE: If you have check for beta versions enabled, you should get notified of a new version and prompted to update in the next day or so. This is the most efficient method (bandwidth wise) as the updates are only ~1/3rd of the size of the full install. Otherwise, you can get the full installation beta HERE. Note that this link will always get you the latest beta version!

[maxoku]

OK - I think I found something - try Beta 57 for me and let me know.

It doesn't happen anymore if only hover is activated, but happens every time if caps lock is also used.