How do I get the code page of the current keyboard layout?

My non-Unicode application needs to be able to handle Unicode keyboard input (WM_CHAR / etc.), Thus getting an 8-bit character code and then converting it to Unicode. 9x compatibility is required, so using most Unicode APIs is not an option.

It is currently looking at the language returned by PRIMARYLANGID (GetKeyboardLayout (0)) and looking at the corresponding code page in the hardcoded table. I couldn't find a function to get the code page used by a specific language or keyboard layout. Character / string conversion can be done with MultiByteToWideChar.

Is there a way to get the current code page of the keyboard layout? GetACP returns the default system code page that is not affected by the current keyboard layout.

+2


source to share


3 answers


Here's another way to do it:



WORD languageID = LOWORD(GetKeyboardLayout(0));
char szLCData[6+1];
GetLocaleInfoA(MAKELCID(languageID, SORT_DEFAULT), LOCALE_IDEFAULTANSICODEPAGE,
               szLCData, _countof(szLCData));
int codepage = atoi(szLCData);

      

+3


source


Although this is an old thread, I just spent most of this morning looking for a method to identify a Windows code page given a specific character set ID (when the current keyboard / locale is not set to that encoding). I realized that the sample code might be helpful to others looking for similar information.

In my case, I wanted to map an encoding value like 161 (Greek) to the equivalent Windows code page, 1253. After a lot of digging, I came up with the following:

/*
 * Convert a font charset value (e.g. 161 - Greek) into a Windows codepage (1253 for Greek)
 */

UINT CodepageFromCharset(UINT nCharset)
{
    UINT nCodepage = CP_ACP;
    CHARSETINFO csi = {0};

    // Note, the symbol charset (2, CS_SYMBOL) translates to the symbol codepage (42, CP_SYMBOL).
    // However, this codepage does NOT produce valid character translations so the ANSI charset
    // (ANSI_CHARSET) is used instead. This appears to be a known problem.
    // See this discussion: "More than you ever wanted to know about CP_SYMBOL"
    // (http://www.siao2.com/2005/11/08/490495.aspx)

    if (nCharset == SYMBOL_CHARSET) nCharset = 0;
    DWORD* lpdw = (DWORD*)nCharset;

    // Non-zero return value indicates success...
    if (TranslateCharsetInfo(lpdw, &csi, TCI_SRCCHARSET) == 0)
    {
        // This should *not* happen but just in case make sure we use a valid default codepage.
    #ifdef _UNICODE
        csi.ciACP = 1200;
    #else
        csi.ciACP = CP_ACP;
    #endif
    }

    return csi.ciACP;
}

      



Hope this is helpful to others!

John

+3


source


I had a similar problem for an application that needed to be run on Windows 9X. The solution I eventually came up with was listening to the WM_INPUTLANGCHANGE notification messages that are sent to top-level windows when the user changes input language. In my post procedure, I have something like this:

case WM_INPUTLANGCHANGE:
  {
    CHARSETINFO cs;
    if (TranslateCharsetInfo((DWORD*)wParam,&cs,TCI_SRCCHARSET))
      m_codePage = cs.ciACP;
    return DefWindowProc(WM_INPUTLANGCHANGE,wParam,lParam);
  }
  break;

      

where m_codePage is a UNIT that is initialized as

  m_codePage = CP_ACP;

      

Then I use m___codePage in the MultiByteToWideChar () calls to handle keys from WM_CHAR, etc.

+1


source







All Articles