2009-08-18 3 views
2

Mon application non-Unicode doit être capable de traiter l'entrée au clavier Unicode (WM_CHAR/etc.), Ainsi recevoir le code de caractère de 8 bits puis le convertir en Unicode. La compatibilité 9x est requise, donc l'utilisation de la plupart des API Unicode n'est pas une option.Comment obtenir la page de code de la disposition de clavier actuelle?

Actuellement, il regarde la langue retournée par PRIMARYLANGID (GetKeyboardLayout (0)), et recherche la page de code pertinente dans une table codée en dur. Je n'ai pas trouvé de fonction permettant d'utiliser la page de codes pour une langue ou une disposition de clavier particulière. La conversion d'un caractère/chaîne peut ensuite être effectuée avec MultiByteToWideChar.

Existe-t-il un moyen d'obtenir la page de codes de la disposition de clavier actuelle? GetACP renvoie la page de code système par défaut, qui n'est pas affectée par la disposition de clavier actuelle.

Répondre

3

Voici une autre façon de le faire:

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

J'ai eu un problème similaire sur une application qui devait fonctionner sous Windows 9X. La solution que j'ai finalement trouvée consistait à écouter les messages de notifications WM_INPUTLANGCHANGE, qui sont envoyés aux fenêtres de niveau supérieur lorsque l'utilisateur change la langue d'entrée. Dans ma procédure de message que j'ai quelque chose comme ceci:

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

où m_codePage est une unité qui est initialisé comme

m_codePage = CP_ACP; 

J'utilise ensuite m___codePage dans les appels à MultiByteToWideChar() pour gérer les clés de WM_CHAR etc.

+0

Cette méthode a un défaut: si la disposition du clavier par défaut ne correspond pas à la page de code du système (CP_ACP), la page de code ne sera pas correcte lorsque l'application démarre. –

3

Bien que thi s est un ancien thread, je viens de passer la majeure partie de la matinée à chercher une méthode pour identifier la page de code Windows ID (lorsque la disposition clavier/locale n'est PAS définie sur ce jeu de caractères). J'ai pensé que l'exemple de code pourrait être utile à d'autres personnes à la recherche d'informations similaires.

Dans mon cas, je voulais associer une valeur de charset tels que 161 (grec) à l'équivalent codepage Windows 1253. Après beaucoup de creuser je suis venu avec ce qui suit:

/* 
* 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 est utile pour les autres!

John

Questions connexes