Is it possible to set something for ALT+TAB like this?

[jhonGL]

Please fill in this template when posting!
XMBC Version: 2.20.5
Installed or Portable version: Installed
Windows Version: 10
Mouse Information (brand/model): Razer Basilisk v3
Relevant Computer Information (CPU, RAM etc): 5000 series AMD
Did the problem occur after an upgrade of XMBC? (If so, from what version?): no
Did the problem occur after a Windows update/upgrade? (If so, from what version?): no
How long have you used XMBC?: 6 months
What language and keyboard layout do you use in Windows?: English US

Clear description of the problem - try and include as much information as possible, including what button and mappings you are having problems with (if applicable).:


I would want to hold Mouse Button 4 and when i hit wheel up or down, the window switcher comes up, wheel up/down moves to the next/previous selection, just like tab/shift+tab, release mouse button 4, selected window is activated.

[jhonGL]

Oh, i think i got something.

Use the chording for Mouse Button 4 + wheel up/down so both bring up ALT-TAB, then have an explorer.exe profile for the CTRL+ALT+TAB window where wheel up is tab, wheel down is shift+tab, mouse button 4 set to enter on release.

I just tested on a fresh program profile with explorer.exe as process to make it activate. What should i add in the window details for the program to pick up exactly the ctrl+alt+tab window and activate it's profile?

Edit: For windows 10 alt+tab window is - process: Explorer.exe, Class: MultitaskingViewFrame

[phil]

Try this (Win10):
Process: Explorer.exe
Class: MultitaskingViewFrame
Match Type: Window and Ancestor Window.

NOTE: To find this, I used the advanced window profile -> Find Window. Turn off CAPS LOCK and tick the "Hover" box in the Find Method.
Then open up CTRL+ALT+TAB switcher and move the mouse cursor over it (actually it seems to be fill screen on the primary monitor).
Turn off caps lock to lock in the profile details and close the task switcher. The Find Window should now be setup as above. I had to select the match type before it would work (be detected as the active profile by XMBC) YMMV.

Bear in mind though, if the active profile changes while a chord is active - it might cause problems (like releasing the chord - not sure).

Regards,
Phil

[jhonGL]

Yes, i made it work, but i soon found out how problematic an infinite scroll wheel can be with chording that involves the wheel...

When in MultitaskingViewFrame, if i hit esc or select something while the wheel is going, whatever is set for wheel up/down in the MultitaskingViewFrame profile (tab/shift+tab in this case) gets leaked to the new window, as the switch to the new profile is not fast enough, even with Enable profile switching on mouse move disabled, priority realtime. Should i play with the hook timeout?

For now, a quick solution with a few lines in an autohotkey script.

#Requires AutoHotkey v2.0

#Hotif WinExist("ahk_class MultitaskingViewFrame")

*WheelUp::Send "{Blind}{Tab}"
*WheelDown::Send "{Blind}+{Tab}"

~XButton1 UP::Enter

#HotIf

A_HotkeyInterval := 0

I don't know how, but autohotkey detects when MultitaskingViewFrame closes even with the wheel going insane when esc is pressed and not a single key is leaked.

So at the moment i just use XMouse Button Control to open ctrl+alt+tab menu and the script takes over.

[phil]

Hook timeouts wont help any here..
You might like to try making the wheel act more like a button - use the "ignore repeated remapped vertical scroll" on the options tab - I'm assuming you have mapped the scroll wheel to something - with that, it will not scroll contentiously but trigger a down when you start scrolling and an up when you stop scrolling - it might not work for you but its worth a try.

XMBC profile switching is delayed intentionally as its very CPU intensive (at least when you have a lot of profiles) so it runs in the background on a timer, and/or when a button (not scroll wheel) is pressed. It would be a significant amount of work to change that reliably, so it might be a problem. I'm not sure if there are any global messages broadcast when the active window changes (but I don't think so else it would have made sense to use that to check the active profile) so I don't know what more could be done there.

Of course, personally I hate infinite, stupidly fast scroll wheels - I like to be precise and have control, but even then in this case it could leak even with a properly notched wheel I guess

[jhonGL]

Thanks for the tips, i played around with "ignore repeated remapped vertical scroll" and it did help.

I think what i want to achieve is a bit much. Holding mouse button 4 and activating another window profile when the wheel triggers ctrl+alt+tab, only to finish it with mb4 release, is an inconsistent thing. I must give up un the mb4 release. Just open ctrl+alt+tab, use the wheel to navigate, left click to select the desired window. Btw, an "ALT-SHIFT-TAB" option in the dropdown could be added for easier selection of a simulated ctrl+alt+shift+tab.

The crazy thing is how fast autohotkey is at detecting that MultitaskingViewFrame window, both at open and at close. I can integrate it in my setup for now.

Yeah, the infinite scroll wheel can be stupid, i find myself playing with it just for fun! It can generate a ridiculous amount of events, without A_HotkeyInterval := 0 , the script was going crazy with the warnings.

[phil]

I should be able to add ALT-SHIFT-TAB - tbh I didn't event know that was an option lol.
And yes, XMBC struggles with the message rate from unlimited scroll wheels sometimes (there is a little code to ignore/throttle messages that happen too fast else all hell can break loose!) - I suspect Windows mouse hooks were never really designed for such fast message delivery!

[phil]

FYI: I've added ALT+SHIFT+TAB to the list in 2.21 Beta 20.