WM_CHAR

When the message queue code page is set to a combined code page, a WM_CHAR message conveys either an SBCS character or a DBCS character depending on what the user typed in. When the current character is an SBCS character, CHAR1FROMMP contains its character code and CHAR2FROMMP contains NULL. When the current character is a DBCS character, CHAR1FROMMP contains the first byte of its character code and CHAR2FROMMP contains the second byte.

┌───────────────────┬────────────────┬────────────────┐
│ Current Character │ CHAR1FROMMP    │ CHAR2FROMMP    │
├───────────────────┼────────────────┼────────────────┤
│ An SBCS           │ Character code │ NULL           │
├───────────────────┼────────────────┼────────────────┤
│ A DBCS            │ First byte     │ Second byte    │
└───────────────────┴────────────────┴────────────────┘
WM_CHAR

The following is the structure of a code fragment which can correctly handle WM_CHAR messages containing both SBCS and DBCS characters.

case WM_CHAR:
    fs = SHORT1FROMMP(mp1);
    ...
    if (!(fs & KC_KEYUP))
    {
      if (fs & KC_CHAR)
      {
        if(CHAR2FROMMP(mp2) != NULL)
        {
          /* WM_CHAR conveys a double-byte character */
        ...
        }
        else
        {
          /* WM_CHAR conveys a single-byte character */
        ...
        }
      }
      else if (fs & KC_VIRTUALKEY)
      {
        /* processing virtual keys */
        ...
      }
    ...
    }
    break;

Another point you have to consider in handling WM_CHAR is that it does not carry a scan code for the characters generated by the input method such as DBCS characters. You should always use character codes rather than scan codes. This is important not only because of the above but also for hardware independence (independence from keyboard types).