The difference between Wm_ime_char and WM_CHAR

To understand the difference between the two, it needs to be clear: the words we play through the keyboard, not all through the input method, after the transfer to the program.

That is: we use the keyboard to hit some of the word is not through the input method directly to the program, such as 1, 2, 3 such as numbers and ABC English letters, carriage return space, etc.

Some are transferred to the program via input method, such as Chinese

Knowing this, the difference between Wm_ime_char and WM_CHAR is easy to understand.

Note: Numbers and English letters you can not input directly through the input method, you can also input through the IME

Wm_ime_char: All characters generated by the input method will generate Wm_ime_char messages. DefWindowProc will convert Wm_ime_char to WM_CHAR message WM_CHAR: The word inode response WM_CHAR message without input method and direct send person program.

Description

For Unicode windows, there is no difference between Wm_ime_char and WM_CHAR, WParam is a WCHAR, which is the character entered.

For non-Unicode (DBCS) Windows, the WParam of Wm_ime_char is a character generated by the IME. This character may be either a single-byte character or a double-byte character. If it is a single-byte character, then it is no different from WM_CHAR, if it is a double-byte character, then the WParam height 8 bits is leading byte, and the low 8 bits is continuation byte.

All characters produced by input methods generate WM_IME_CHAR messages instead of WM_CHAR, but DefWindowProc converts wm_ime_char to the corresponding one or two WM_CHAR messages.

For example: Do not open Input Method input "9"→ receive WM_CHAR (0x0039) Open Input Method input "9"→ received Wm_ime_char (0x0039) → received wm_char (0x0039) Open Input Method Input "stupid"→ received Wm_ime_cha R (0XB1BF) → received wm_char (0x00b1) → received wm_char (0X00BF)

Programming Implementation:

For WM_CHAR MFC provides its response function OnChar (), but for Wm_ime_char does not provide its response function, we need to write

The following example shows how to process a keyboard character message:

1) Define a global array that holds keyboard input characters

	wchar_t m_imechar[2];

Characters commonly used Unicode occupies 2 bytes

The Unicode of the obscure character takes 4 bytes

So, define 4 of your own array of stored words

2) Reload window processing Process

	Virtual LRESULT WindowProc (UINT message, WPARAM WPARAM, LPARAM LPARAM);

WindowProc (UINT message, WPARAM WPARAM, LPARAM LPARAM)
{
	switch (message)
	{case
	Wm_ime_char:
		// Preprocessing of special characters
		if (pretreat (Wm_ime_char,wparam,lparam)) break;

		Other characters into the array
		if (m_imechar[0]>=0xd800 && m_imechar[0]<=0xdbff)
		{
			m_imechar[1]= (wchar_t) WParam;
		}
		else
		{
			m_imechar[0]= (wchar_t) WParam;
			if (m_imechar[0]>=0xd800 && m_imechar[0]<=0xdbff) break
				;
		}	
		Onimechar (M_imechar);
		break;
	Default: Break 
		;
	}
	return Cscrollview::windowproc (Message, WParam, LParam);
}

Description

Unicode encoding u+0000 ~ U+FFFF to basic multi-language plane (basic multilingualplane, précis-writers to BMP)

u+10000 ~ U+10FFFF for 16 auxiliary planes

Characters commonly used are in BMP, which accounts for 2 bytes, while the obscure word is four bytes outside of BMP.

Characters commonly used, obscure word difference method:

Within the BMP, the code point section from u+d800 to U+DFFF is permanently reserved and does not map to characters

BMP takes four bytes and the first two bytes are high byte and the last two bytes are low byte

The first two bytes are in the range: 0xD800. 0xDBFF

The following two bytes are in the range: 0XDC00. 0xDFFF

Thus, the characters within the BMP and the characters outside the BMP do not intersect.

So

if (m_imechar[0]>=0xd800 && M_IMECHAR[0]<=0XDBFF)

If this condition is met, it represents a 4-byte obscure word

For the obscure word, the system sends two WM_IME_CHAR messages, transmits its high byte for the first time, and transmits its low byte for the second time.

When running to Onimechar (M_imechar), M_imechar stores the real word (either characters commonly used or obscure word, at which point it is ensured that the array is present)

3) Processing of accepted words in an array

	void Onimechar (wchar_t* Str);

Onimechar (wchar_t* Str)
{
	...
}		

4) Use OnChar to respond to characters that are not input by input methods

OnChar (UINT NChar, uint nrepcnt, uint nflags)
{
	switch (NChar)
	{case
	0x0D:													//Enter
		if (pretreat (0x0d,null,null)) break;

		Onenterkeydown ();
		Update ();
		break;
	Case 0X08:													//BACKSPACE bar
		if (pretreat (0x08,null,null)) break;

		if (M_paselelem.getsize () >0) Ondelelemsel ();
		else Onbackspacekeydown ();
		Update ();
		break;
	Case 0x20:													//SPACEBAR
		if (pretreat (0x20,null,null)) break;

		Onspacekeydown ();
		Update ();
		break;	
	Case 0x09:													//tab key
		if (Pretreat (0x09,null,null)) break;

		Ontabkeydown ();
		Update ();
		break;
	Default: Break
		;
	}

	if (M_paselelem.getsize () >0)
	{
		cleanselelem ();
	}

	Cscrollview::onchar (NChar, nrepcnt, nflags);
}

Principle of Treatment:

For Wm_ime_char messages, it is referred to the WM_IME_CHAR response function for processing

For character messages that do not have input methods, they are referred to WM_CHAR for processing

Resources:

http://timothyqiu.com/2012/wm_ime_char/