X-MBC keeps blocking input in Windows 10

[phil]

If you can reproduce this fairly reliably, esp using alongside AHK scripts, maybe that will help me reproduce it too and then it might be easier to find a fix in XMBC itself... Its one of those really annoying ones that is difficult to reproduce and when it does happen Im doing something else and don't get a chance to fire up the debugger (its working again by the that can happen lol). Its probably something really silly, but finding these things is a nightmare!

I was curious about the mousevent thing because that, in theory is an old depreciated API that was replaced with SendInput so curious as to why it might help - unless the problem is in Windows itself!

[Lores]

I have managed to come up with a predictable and repeatable test for showcasing of such blockade: it utilizes global Button Chording for usage of Windows' Magnifier. And it happens when no AHK script and / or and HotkeyP is running on my system; as well when they are running

In this logged test I started with magnify.exe already being turned on [in full screen mode]. I was able then, after executing few zoom in and zoom outs, to move around the Magnifier window that holds its controls. Then I closed Magnifier and reopen it using X-MBC. At first I could also move its window, but a second attempt [preceded with more Button Chording usage] fails - meaning the blockade has kicked in. When input was blocked I could still left click on Magnifier's icon pinned to Taskbar in order to hide [minimize] and show its window- but nevertheless when it was shown then left clicking any of its buttons was yielding no response. I could however evoke with right click the context menu for its icon on the Taskbar in order to close it with left click. But despite doing so input was not unblocked. It was only after pressing of CTRL + ALT + END was I able to regain control


And on a side note: why does the LOG file keep referencing to the

C:\Program Files Expanded\X-Mouse Button Control\XMBCSettings.xml

path of an installed version when I no longer have it on my system and also tries to access my former portable path of

C:\Program Files Expanded\X-Mouse Button Control\XMBCSettings.xml

when my current one is

C:\q\X-Mouse Button Control

in which however I do not have that XMBCSettings.xml file nor have it anywhere on my volumes?

[Lores]

As for blockades of input under other circumstances

[...]
like when trying to cop / paste / cut text when in Notepad3 and Thunderbird
[...]

they still do annoyingly happen but are not precisely repeatable and often are not so firm / total i.e. hotkeys defined in HotkeyP are blocked but other input is not and it can unlock itself upon some window switching or closing and re-opening of HotkeyP or after just closing of X-MBC [which closing does not require an intermediary ease-up in form of evoking of the Task Manager window]

And as now

I have managed to come up with a predictable and repeatable test for showcasing of such blockade
[...]

I do not know if there is a sense in you analyzing my manual log / itinerary [in which long periods of time without entries indicate a lack of testing and not a usage of X-MBC free of blockades / freeze-ups]

[Lores]

I have also started a topic on the AutoHotkey forum, in which point out to a possibility of the Magnifier itself being the culprit: https://www.autohotkey.com/boards/viewt ... 6&t=119902

But then again if it would be the case, then it still would not account for

[...]
blockades of input under other circumstances

[...]
like when trying to cop / paste / cut text when in Notepad3 and Thunderbird
[...]

[...]

thus would not solve the core issue laying somewhere in X-MBC


And what about my Settings and Profiles- do you not need them as well alongside that LOG file?

[phil]

Yes settings and profiles always worth sending too as it helps to know the entire setup (forgot to ask for them).
I'm really busy at the moment so I haven't got much time to spend on XMBC but I will try and find some time to grab a quick look. The problem I have is reproducing it, especially under debugger conditions can be quite tricky/time consuming, especially if its timing related (so it may behave differently or never happen on different setups) or takes a long time to happen.

Normally input getting blocked is a sign that something in Windows has gotten confused, either a click is not released when it should be, or the mouse hook is removed by Windows for whatever reason (and it does not notify when this happens) although usually that just results in XMBC not working rather than blocked input.

The first question, is... Is XMBC receiving the input and blocking it, or is XMBC not receiving the input either. If its the former, it should be relatively easy to spot/debug but the second option means something in the windows messages queues must have gone wrong (which I have no visibility of) and working out what triggered it to go wrong in the first place is incredibly difficult - maybe not even possible!

[Lores]

[...]
And what about my Settings and Profiles- do you not need them as well alongside that LOG file?

Yes settings and profiles always worth sending too as it helps to know the entire setup (forgot to ask for them).
[...]

Recuse of this issue viewtopic.php?t=4755, just to be on the safe side, I have archived my entire portable folder of X-MBC

[Lores]

[...]
And what about my Settings and Profiles- do you not need them as well alongside that LOG file?

Yes settings and profiles always worth sending too as it helps to know the entire setup (forgot to ask for them).
[...]

Because of this issue viewtopic.php?t=4755, just to be on the safe side, I have archived my entire portable folder of X-MBC, in a state not long from that time when the that LOG file was created

[Lores]

[...]
I do not know if there is a sense in you analyzing my manual log / itinerary
[...]

I forgot to add to it this prepared a long time ago info:

The freeze-up from 16-02-2023 22:27 is significant: I carefully double checked if I really was experiencing what I was thinking that I was - and indeed it was a case when X-MBC had been closed a long time ago. And such glitches were happening also in days before this, i.e. without X-MBC. It is clear now that either X-MBC something imprints on system - or HotkeyP causes the same issue as your program

Most of freeze ups are absent from the reported, because I was not sure what exactly and where I was clicking and / or what happened ; or I was just too busy to write them down

And yes: I can confirm now [that much more time has passed] that very rarely also HotkeyP can cause some similar blockades [when X-MBC is not being used]

[Lores]

Have you managed to do any progress?

HotkeyP still keeps rarely blocking input. I think I need to once more try out different settings for it, as it might lead to pin pointing to what catalyzes blockades also in X-MBC; right?

[phil]

Nope, haven't even looked at it to be honest. Other than some generic improvements, which I guess haven't made much difference (are you keeping up with the latest Beta's?)
Unfortunately, trying to track down issues like this, that can not be reproduced here (under the debugger) is incredibly difficult as there are so many environment issues out of my control. Maybe the problem is not in XMBC at all but something else I have no visibility of - really tricky!