最近博主遇到一个很奇怪的问题：
CreateWindow( //edit控件
"edit",
"",
WS_VISIBLE | WS_CHILD | WS_BORDER/*|DT_CENTER*/ | DT_VCENTER,
100, 70, 100, 25,
hWnd,
NULL,
NULL,
NULL);
创建了一个edit控件，看起来没有什么问题，运行一下：
会发现无论怎样敲击键盘，Edit都不会接收键盘输入的字符，经过博主的调试以及摸索发现：EDIT控件只接受WM_CHAR字符消息，而不是WM_KEYDEMO这样的虚拟键代码消息，所以我们需要在消息循环函数里使用：
TranslateMessage来将虚拟键代码消息转换成WM_CHAR消息派发出去：
// 获取消息
while (GetMessage(&msg, NULL, 0, 0)) // 当接收到WM_QIUT消息时，GetMessage函数返回0，结束循环
{
TranslateMessage(&msg);
DispatchMessage(&msg); // 派发消息，到WindowPro函数处理
}
再次运行就发现可以输入了：
但是还有一个问题，是博主没有加TranslateMessage的时候使用输入法汉字模式下可以输入，原因在于：当我们把焦点放到一个窗体或控件上的时候，按下键盘上的任何按键，输入法会自动获取焦点窗口句柄，然后将我们所按下的每一个按键在自己的汉字库里面寻找，将结果保存成一个链表，每一个汉字没有具体的ascii码表的对应，因为编码的不同，比如：
gb2312:
high8 = 0xa1-->0xfe （161 - 254）
low8 = 0xa1-->0xfe （161 - 254）
gbk:
high8 = 0x80-->0xfe （128 - 254）
low8 = 0x40-->0xfe （64 - 254）
比如你的系统使用的汉字编码是gbk，那么你就要发送两次，第一次发送高位，第二次发送低位即可！
而edit控件会根据编码的不同来接受不同的字符信息，但是edit每次只能处理wm_char消息一次，当我们发送汉字的时候需要两次，但是汉字对应的ascii码不在英文的ascii码的对应表里，所以edit会认为这是一个汉字，就等待下一次的接受，下一次接受的数据会在编码表里寻找对应的编码，如果长时间没有收到则会视为无效ascii 码，打印出未知的字符！
但是如果你的系统是unicode(包含utf-16)编码(宽字节底层也是这种编码)，一次发完即可！
这里在补充一个小知识，那就是每个键盘的键代码可能不一样，也就是扫描码，当出厂商在制作键盘时，每按下一个按键，都会修改指定寄存器里的值，这个值里面包含了键代码，但是有的键代码可能不一样，所以诞生了驱动文件来告诉操作系统键代码对应什么键！