WM_CHAR !?

[Pogacha]

Desde la msdn tengo que:

The WM_CHAR message uses Unicode Transformation Format (UTF)-16.

Pero voy a mi casa y en realidad me da un char mapeado en codepage ... y no encuentro otra documentación que me diga que pasa.
Mas detalles: he creado un bitmap fonts correspondiente al latin-1 codepage tal como lo especifica M$, luego al precionar las teclas extendidas "é" "ñ" el valor que tengo en wParam no es otro mas que el correspondiente al codepage. En definitiva me anda perfecto para latin-1.

El problema es que tengo que hacer una versión Windows-1251, pero no tengo un teclado ruso como para comprobar que esté andando y tengo mideo que el latin-1 me halla coincidido con el utf-16 y como perro esté malinterpretando el concepto. Pero tampoco encontre una tabla con el utf-16 como para comprobarlo y no se donde mas buscar.

¿Alguien me explica como es?

Muchisimas gracias!

[_Grey]

No estoy seguro de entender lo que dices...  :?  
.. pero creo comprender que estas trabajando con WM_CHAR para leer el teclado, y te funciona bien, el problema es que no sabes si tirara bien cuando tenga que leer un valor de 16bits (UNICODE), es eso no!?

No he lidiado este problema con profundidad pero recuerdo algunas cosas que tengo en un libro del Ventanucos.
Si registraste la clase con RegisterClassA, recibiras ANSI; si RegisterClassW recibirás UNICODE, el valor de 16bits que creo te preocupa; si lo hiciste con RegisterClass, "a secas", dependerá de si tienes activado UNICODE en el preprocesador.

Cuidado con activar el UNICODE en el preprocesador, por que te cambiara todas las funciones de windows preparadas para UNICODE de como las tenias en ANSI, si has usado _TEXT no tendrías de que preocuparte... creo.

Si no estas seguro de nada, con IsWindowUnicode() deberías obtener si la ventana obtendrá ANSI o UNICODE, en WM_CHAR.

A partir de ahí, supongo que si sale algo mal sera de que el bitmap con el font de windows-1251 no sea correcto.

...
...
...

Por otro lado estoy viendo que Window-1251 tiene 256 caracteres... si lo tienes en ANSI te debería valer no!??!?!
Eso si, asegurate que tienes el TranslateMessage(), en el bucle de mensajes, que es el que se encarga de que WM_CHAR funcione bien.

Espero que sirva y no lo haya complicado mas....Saludos.

[EDIT]
que caotico no.... :x  :|

[Pogacha]

No he lidiado este problema con profundidad pero recuerdo algunas cosas que tengo en un libro del Ventanucos.
Si registraste la clase con RegisterClassA, recibiras ANSI; si RegisterClassW recibirás UNICODE, el valor de 16bits que creo te preocupa; si lo hiciste con RegisterClass, "a secas", dependerá de si tienes activado UNICODE en el preprocesador.

Este era mi problema!
Leyendo un poco mas las MSDN lo encontré y volvia para comentarlo cuando leí tu respuesta.
Muchas gracias!

EDIT: El 1251 tiene los 128 del ascii y luego 128 caracteres rusos y si me andaba, pero no podia probar que los simbolos que salian eran los correspondientes a las teclas que tocaba (no tengo un teclado ruso :P ).

[Pogacha]

Por si alguno le interesa ...

Para guardar compatibilidad con Win98 y otras plataformas no te conviene usar los macros TCHAR y _T(), sino mas bien trabajar todo en wchar_t y luego cuando tengas que usar un servicio de windows haces:

Código [Seleccionar] Expand

void Func( wchar_t *s )
{
 if(WindowsVersion == NT)
 {
    WindowsFunctionW( s , ... )
 } else {
    char temp[128];
    WideCharToMultiByte(CO_ACP, s , -1,  temp, ... );
    WindowsFunctionA( temp, ... );
 }
}

Win9X / ME no tienen soporte unicode nativo y deberas usar las *A entonces.
WinNT/2K/XP si tienen soporte unicode nativo y funcionan mejor con ello.
De esta manera tendras un elegante codigo sin preocupaciones.
Otra opcion es usar UTF8 y luego decantar por multibyte (*A) o utf-16 (*W). Con una buena clase que la encapsule podrias darte maña ya que utf8 encierra tanto ASCII asi como tambien UNICODE completo a diferencia de utf-16 que solo llega hasta 16 bits.
Lamentablemente, yo aún no tengo la suficiente seguridad en el tema como para decantar por usar este sistema (utf-8), aun que los mas duchos aseguran que este es el mejor.
Tampoco encontré ninguna implementacion de una clase StringUtf8 en la red, y hay que tener en cuenta muchas cosas para su implementación, como las inserciones/modificaciones y el problema de los archivos de texto donde le retorno de carro puede ser confundido en una transcodificación. Tambien me asusta la compatibilidad de los compiladores, pues si quieres agregar texto embebido, el compilador deberá ser compatible con utf-8 y no estoy seguro de que todos lo sean.
Hasta el momento tengo separadas dos clases String (ansi) y WString (utf-16)  + Parser y WParser y me va bien con ellas ...
Tal vez agrege una UTF8Parser que se comunique a travez de WStrings.
Bueno, por si a alguien le interesaba ...
Saludos.