none
Bug in Windows 10 version 1903? RRS feed

  • Question

  • Hello All,

    We've found out a change in the behavior of the ImmGetVirtualKey function (Imm32.dll). We use that function to detect whether the IME is on or off. Prior to Windows 10 v 1903, this function returned a virtual key code if the IME was enabled, and the VK_PROCESSKEY key code if the IME was not used. After update 1903, this function always returnы the virtual key code regardless of the IME state.

    Does anyone experience this issue?


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Wednesday, June 19, 2019 9:08 AM

All replies

  • Hello Andrei Smolin,

    Yes, on 1903, ImmGetVirtualKey function always return virtual key regardless if TranslateMessage has been called by the application. But on 1809 it always return VK_PROCESSKEY regardless if TranslateMessage has been called by the application.

    I test using the following code with "TranslateMessage(&msg);" commented and uncommented in the message loop.

    	case WM_KEYDOWN:
    	    {
    			result = ImmGetVirtualKey(hWnd);
    			if (VK_PROCESSKEY == result)
    			{
    				MessageBox(hWnd, L"VK_PROCESSKEY", NULL, 0);
    			}
    			else
    			{
    				MessageBox(hWnd, L"virtual key", NULL, 0);
    			}
    			break;
    	    }

    So I have some questions:

    Do you mean "IME is on or off" that with and without TranslateMessage has been called? If yes, do you test on 1809? If not, how do you turn IME on and off and what your reproduce demo and steps?

    Best regards,

    Rita



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.


    Thursday, June 20, 2019 3:07 AM
    Moderator
  • Hello Rita,

    We develop plugins that work in Microsoft Office applications which can grab keyboard input messages. The messages are required for our UI to work. To get these messages, we set a keyboard hook via SetWIndowsHookEx(WH_KEYBOARD, CallbackFunction): when a message arrives, we process and mark it as handled: the callback function returns 1.  When IME works, we must let it process the message; therefore, the callback function must return 0 in this case. In other words, we need to have a way to detect if IME is working or not. We use ImmGetVirtualKey() to get this info:

    int CallbackFunction(int code, IntPtr wParam, IntPtr lParam)
    {
           if (code == 0) 
    {
                  int vkey = ImmGetVirualKey(hwnd);
                  
    // in 1809
                  // if keyboard locale is, for example, Japan (Hiragana) – IME is open
                  // ImmGetVirtualKey returns the actual virtual key code
                  // if keyboard locale is English, German, Czech, French – no IME
                  // ImmGetVirtualKey always returns VK_PROCESSKEY
    
    // in 1903
                  // if keyboard locale is, for example, Japan (Hiragana) – IME is open
                  // ImmGetVirtualKey returns the actual virtual key code
                  // if keyboard locale is English, German, Czech, French – no IME
                  // ImmGetVirtualKey returns the very same virtual key code
    
                  return 1;
    }
           else
                  return CallNextHookEx(hHook, code, wParam, lParam)
    }
    

    We can't use IMEGetOpenStatus() since the status can be changed by IMESetOpenStatus().

    As to TranslateMessage, we call it after calling ImmGetVirualKey.

    Here's the test scenario. Add a system language supporting IME, say, Japan (Hiragana). When the focus is in a text box, switch to that language and try to enter something. We expect this function to return the actual virtual key code. Now close the IME editor, switch to a non-IME language and press a key. In this case, the result depends on the Windows 10 version used: in 1903, this function returns the virtual key; in 1809, you receive VK_PROCESSKEY.


    Regards from Belarus (GMT + 3),

    Andrei Smolin
    Add-in Express Team Leader

    Please mark answers and useful posts to help other developers use the forums efficiently.

    Thursday, June 20, 2019 2:11 PM
  • Hi Andrei,

    Thanks for reporting this issue. 

    I have also reported it and you can refer the status of this issue via link below:

    https://aka.ms/AA5i1at

    Regards & Fei


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, July 3, 2019 5:47 AM
  • Hello,

    The link to the reported issue is inactive and redirects to a blank feedback form. This issue with the API still exists in Windows 10 update 1903, and I wanted to know if it was resolved for a future update.

    Thank you,

    Tuesday, October 29, 2019 5:13 PM