Window switcher: the key above Tab is not always VK_OEM_3

[tesivo]

Regarding the "Window switcher" feature, activating the "Windows 10" style:
ALT+TAB and ALTGR+TAB works correctly, but the ALT+@ and ALTGR+@ combinations also activate the feature, preventing the @ character from being typed except via ALT+064.

[valinet]

It’s probably VK_OEM_3 key which represents the ~ key on US English keyboards. Alt+~ activates the window switcher showing windows only for the active application; anyway, you obtain @ with Alt in Italian instead of Shift? That’s interesting. On what key is @ physically in Italian? Can you show me a picture, please? Of course, I’ll do some reading and figure out a solution. I saw this feature in GNOME previously, as far as I remember. I wonder how they tackle it there…

[tesivo]

Yes, that does seem to be the problem. The keyboard with the Italian layout doesn't have the ~ key, so I get it by pressing ALT+126.

Italian Layout:
http://kbdlayout.info/kbdit

Italian Layout Virtual Keys:
http://kbdlayout.info/kbdit/virtualkeys

It seems to be VK_OEM_3. I get @ by pressing ALTGR+ò.

P.S. It's actually not the same Windows switcher, I didn't notice :)

[plofhaan]

Similar problem here: with the AZERTY BE keyboard layout, ~ is typed by pressing Alt Gr + = before pressing spacebar.

[plofhaan]

I get @ by pressing ALTGR+ò.

I get @ by pressing Alt Gr + é.

[valinet]

So, the window switcher should not be activated by AltGr anyway, it does not even make sense, would disabling the AltGr+Tab combination but keeping Alt+Tab solve the issues presented here?

[tesivo]

Yes! It should solve the issues.

[valinet]

Well, it's actually more complicated, I have looked into it just now. Basically, the window switcher containing only the windows of the active application should be triggered by pressing Alt+"the key above Alt". Unfortunately, for US English, the virtual key code for that is VK_OEM_3, while for other languages it can be whatever, like VK_OEM_5 for Italian as the diagram you provided me shows. Thus, it means that to correctly deliver this functionality, the registered hot key should change and register based on the active keyboard layout. I will find a way to have some logic that changes the hot key to the correct VK_OEM_... key when the keyboard layout changes. Scan codes stay the same and that+some keyboard layout gets you a certain virtual key code. Unfortunately, RegisterHotkey, which is what I use to get notified about key combinations only accepts registering using virtual key codes, not scan codes. Anyway, I will solve this, but it is going to take some time.

Thanks

[tesivo]

Thank you!

If I understand correctly it's not a simple matter to just disable the ALTGR+TAb combination and then ATLGR+@ so I was thinking, what if it was possible to select from a drop down menu which VK_OEM_# key to use by putting for example:

• American VK_OEM_3
• Italian VK_OEM_5
• French VK_OEM_7
  And so on. It seems to be from number 1 to number 7. I guess the solution is not elegant.

Thanks again!

[BraINstinct0]

Thank you!

If I understand correctly it's not a simple matter to just disable the ALTGR+TAb combination and then ATLGR+@ so I was thinking, what if it was possible to select from a drop down menu which VK_OEM_# key to use by putting for example:

• American VK_OEM_3
• Italian VK_OEM_5
• French VK_OEM_7
  And so on. It seems to be from number 1 to number 7. I guess the solution is not elegant.

Thanks again!

Or a dirtier but more robust solution would be to make the key config configurable, I.E. asking users to input key combinations to use for window switching.(Not saying that it'll be implementable or not, but this seems to be something many programs are using.)

[valinet]

@BraINstinct0 @tesivo I don’t think choice in the area makes sense: Alt-Tab is Alt-Tab, it has to be invoked with Alt-Tab. Similarly, Alt-(key above Tab) is a natural extension to that. Similarly, choice for that doesn’t make sense for people. What are VK_OEM_… for regular people? Even if they know, they’d have to choose by trial and error when the correct key can in fact be easily determined in software based on the scan code (which is always 29) and the current keyboard layout. And if they choose manually, it still breaks when switching keyboard layouts.

I already mentioned this in the previous reply, I will make sure the hotkey is always Alt+the key above Tab. That was the intended behavior from the get go, so I will stick to that.

AltGr is mainly equivalent to Ctrl+Alt. It’s not an issue if the key I choose does not have any meaning with AltGr pressed, and it seems to me that the key above Tab doesn’t type yet another character when AltGr is pressed.

[tesivo]

Nice, you convinced me, really better to leave the behavior you expect with the key/key combination you expect.

AltGr is mainly equivalent to Ctrl+Alt. It’s not an issue if the key I choose does not have any meaning with AltGr pressed, and it seems to me that the key above Tab doesn’t type yet another character when AltGr is pressed.

I confirm, ALTGR+(key above TAB)does not type any characters.

[valinet]

Implemented in 22000.282.33.0: the key above Tab is now always correctly identified for all keyboard layouts. During the research for enabling this functionality (which was kind of a PITA, thanks to how overly complicated, undocumented and outdated the APIs are - I ended up using yet another undocumented API), I was also able to add a new functionality to the patcher, namely the ability to reenable the old Windows 10 language switcher flyout:

Hopefully this patch fixes this issue properly. I tested it with Italian, Belgian, Lithuanian (as that has 2 layouts, one with key above Tab mapped to VK_OEM_3 and one mapped to VK_OEM_5). It seemed to work fine on my machine. The code also now contains a very nice example on how to be notified as a background application of keyboard layout changes and how to determine the keyboard layout the user switched to from that, plus all the string shown in the taskbar, like "ENG", "US", "English (United States)", "US keyboard", "en-US" etc. I couldn't make it work with the official APIs, which seemed to notify only when the window was the foreground window, so resorted to checking out how explorer does it and have implemented that.

Rgarding AltGr, that is simply not a separate key, but actually Alt+Ctrl, which I already map for persisting the switcher, but considering the changes I made here, it should be fine.

[Galixte]

Hello @valinet,

I think I encounter a similar issue with this.

Since the https://github.com/valinet/ExplorerPatcher/releases/tag/22000.348.40.0_c7c94b3 release a new switcher mode "Simple Window Switcher" appeared.

Only with this mode selected, If I use the keyboard key combination Alt Gr + ² (for a French AZERTY keyboard) = Alt Gr + ~ (left of number 1 - for US keyboard) it displays the window switcher with only the current window, while Alt + Tab displays the window switcher with all opened windows.

IMO the action produced by the combination of the Alt Gr + ² = Alt Gr + ~ is useless, moreover I use a software (enhanced FRENCH keyboard) and this software permit me to write the following character « (it’s an opening French inverted commas) with the combinaison keys: Alt Gr + ².

So, could you remove the shortcut Alt Gr + ² = Alt Gr + ~ when the window switcher is activated as "Simple Window Switcher" mode?

Kind regards.

[valinet]

It's not an issue, it's actually intended functionality. The Simple Window Switcher basically offers 2 types of window lists:

• Alt+Tab - a list of all windows on the screen
• Alt+"key above Tab" (aka "key left of digit 1") - a list of windows belonging to the current application

The last behavior is similar to what some window manager on GNU/Linux-based distributions offer. It's a nice perk. That being said, I understand what you describe, you want a way to disable that functionality alone in order to map the available key to whatever thing you want it mapped to. Okay, I will include an option to disable that specific functionality in a coming update, because I think it is useful to have for certain users. I will publish it as soon as I get it done.

Thanks

[Galixte]

Thanks you so much!

[valinet]

Implemented an option to disable that combination in pre-release 40.2.

[Galixte]

It works like a charm, thanks!