最近博主遇到一個很奇怪的問題：

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)編碼(寬位元組底層也是這種編碼)，一次發完即可！

這裡在補充一個小知識，那就是每個鍵盤的鍵程式碼可能不一樣，也就是掃描碼，當出廠商在製作鍵盤時，每按下一個按鍵，都會修改指定暫存器裡的值，這個值裡面包含了鍵程式碼，但是有的鍵程式碼可能不一樣，所以誕生了驅動檔案來告訴作業系統鍵程式碼對應什麼鍵！