Sorry, it’s difficult for me to clearly describe the specific issue in the title. English is not my native language, so summarizing the problem in one sentence is quite challenging for me. Please understand.

I am using SendMessage in AHK v2 to call WM_INPUTLANGCHANGEREQUEST in order to create a quick input method switcher. When tested in other processes, everything works fine, but two unexpected issues occur in Windows Explorer:

1. When the hWnd specified by WM_INPUTLANGCHANGEREQUEST is the taskbar (ahk_class Shell_TrayWnd), it cannot modify the keyboard layout. I specifically tested this with the native Windows hotkey Win + Space, and confirmed that when the taskbar is selected, it should switch the keyboard layout. However, the WM_INPUTLANGCHANGEREQUEST message does not have any effect on it, even if it is running as administrator.

2. There’s an issue where the input method changed by WM_INPUTLANGCHANGEREQUEST does not “persist” in Explorer. I have ensured that the “Let me use a different input method for each app window” option in Keyboard Settings is turned off, and I have double-checked the environment to ensure that only WM_INPUTLANGCHANGEREQUEST is operating on the keyboard layout. Now, the issue: when I use WM_INPUTLANGCHANGEREQUEST in Explorer to switch the input method, for example from ENG to Chinese, it switches normally. However, when I switch to another Explorer window (or switch to another any window then switch back), it immediately reverts to the previous keyboard layout—ENG. If I use Win + Space instead of WM_INPUTLANGCHANGEREQUEST, it maintains the Chinese keyboard layout when switching to another Explorer window, which is the expected behavior. That is to say, WM_INPUTLANGCHANGEREQUES in Explorer seems to be only able to “temporarily” modify the keyboard, once the window is activated again, it will be automatically restored to the previous keyboard layout by the system.

Here is my code.

#Requires AutoHotkey v2.0

; Change to Next Language Layout on ImmGetDefualtIMEWnd of current actived window
~LCtrl:: {
    SendMessage(0x50, 0x0002, , , DllCall("imm32ImmGetDefaultIMEWnd", "Uint", WinGetID("A")), 1000)
}

; Change to Next Language Layout directly on current actived window
~LShift:: {
    SendMessage(0x50, 0x0002, , , WinGetID("A"), 1000)
}

For those who are very familiar with Windows API but not with AHK, I apologize. However, I have not yet mastered the syntax for hooking the keyboard and using Windows API in other languages. But this code is simple and easy to understand, and if possible, I hope that friends who are proficient in other languages can help test it with another language to see if the issue is with AHK or with the WM_INPUTLANGCHANGEREQUEST message itself.

In order to test on a computer without a Chinese keyboard, I have made some modifications and removed the redundant parts, leaving only the section that ensures the issue will occur.

The above two kinds of Hotkeys can reproduce the above problems.

Is this an issue inherent to WM_INPUTLANGCHANGEREQUEST itself?
How can I solve these two problems:

1. How to modify the keyboard layout when the taskbar is activated？

2. How to avoid the system automatically reverting back to the previous keyboard layout after switching with code? Are there any methods other than WM_INPUTLANGCHANGEREQUEST to switch to any language keyboard layout at will?

WM_INPUTLANGCHANGEREQUEST has the advantage of being able to specify the language directly. My code above was changed to switch to the next keyboard layout just for convenience in illustrating the situation. In short, I don’t want to use code to trigger hotkey like win+space that only switch to the next input method, as it doesn’t meet my needs.