I need to test if this works for all patterns (each characters, each CJK languages).

Hi @Yuki Hashimoto (hzuika).

I need some explain.
Would you explain below, please?

1. Is it your patch's summary below, ok? (It is my understanding.)

/* When the IME is enabled, input events are superseded by WM_IME_STARTCOMPOSITION or
         * WM_IME_COMPOSITION messages. Therefore, NULL is returned here. However, some keys are
         * not handled by IME, so they are temporarily stored (ImeNotHandledEventCandidate) and
         * used when WM_CHAR message is posted.
*/


- ImeNotHandledEventCandidate (GHOST doesn't not need to pass these keys to IME. i.e. not character keys.)
  - GHOST_kKeyLeftShift = 0x100,
  - GHOST_kKeyRightShift,
  - GHOST_kKeyLeftControl,
  - GHOST_kKeyRightControl,
  - GHOST_kKeyLeftAlt,
  - GHOST_kKeyRightAlt,
  - GHOST_kKeyOS,     /* Command key on Apple, Windows key(s) on Windows. */
  - GHOST_kKeyGrLess, /* German PC only! */
  - GHOST_kKeyApp,    /* Also known as menu key. */

  - GHOST_kKeyCapsLock,
  - GHOST_kKeyNumLock,
  - GHOST_kKeyScrollLock,

  - GHOST_kKeyLeftArrow,
  - GHOST_kKeyRightArrow,
  - GHOST_kKeyUpArrow,
  - GHOST_kKeyDownArrow,

  - GHOST_kKeyPrintScreen,
  - GHOST_kKeyPause,

  - GHOST_kKeyInsert,
  - GHOST_kKeyDelete,
  - GHOST_kKeyHome,
  - GHOST_kKeyEnd,
  - GHOST_kKeyUpPage,
  - GHOST_kKeyDownPage,

2. About the timing of input event flow and new IME's event behavior.

In past, you explain about the flow of processing input and new IME's event flow. (https://developer.blender.org/D11929#308878).
This patch uses WM_IME_STARTCOMPOSITION, but isn't it problem about the timing in this case of this patch?

@Takahiro Shizuki (sntulix)

Thank you for your comment.
I apologize for the lack of explanation.
I try to write a detailed explanation.

Hi @Takahiro Shizuki (sntulix) . If the explanation below is difficult to understand, please ask.

1

ImeNotHandledEventCandidate (GHOST doesn't not need to pass these keys to IME. i.e. not character keys.)

Sorry, the name of ImeNotHandledEventCandidate() may be misleading.
ImeNotHandledEventCandidate() returns true when the key is all drawable characters(alphabet, symbols, numbers) and some control keys(Enter, Backspace, Tab, Etc)
These keys sent WM_CHAR message or WM_IME_*COMPOSITION messages.
ImeNotHandledEventCandidate() returns false when the key is a control key(Ex: F1, Arrow, Delete, Home, End, Shift, Control) without above.
These keys do not sent WM_CHAR message and WM_IME_*COMPOSITION messages (only WM_INPUT messages).

2

I explained like this, but this has mistakes.

Press any key when IME turns on
↓
WM_INPUT
The character is processed by IME? →No Add GHOST_kEventKeyDown Event
↓Yes
WM_IME_STARTCOMPOSITION
(Remove GHOST_kEventKeyDown Event)
↓
WM_IME_COMPOSITION
Add GHOST_kEventImeComposition Event
↓
Process GHOST_kEventImeComposition Event

Current approach

Press any key when IME turns on
↓
WM_INPUT
The character is processed by IME? →No (Return GHOST_kEventKeyDown Event)
↓Yes (Return NULL)
WM_IME_STARTCOMPOSITION
(Return GHOST_kEventImeCompositionStart Event)
↓
WM_IME_COMPOSITION
(Return GHOST_kEventImeComposition Event)

This patch suggest the following approach.

Press any key when IME turns on
↓
WM_INPUT
The character is control key (= does not sent messages bellow)? → Yes (Return GHOST_kEventKeyDown Event).
↓No (Return NULL)
1 WM_CHAR (Return original GHOST_kEventKeyDown Event)
2 WM_IME_STARTCOMPOSITION (Return GHOST_kEventImeCompositionStart Event)
↓
WM_IME_COMPOSITION (Return GHOST_kEventImeComposition Event)

This patch is an attempt to improve IsImeKeyEvent, which is becoming more complicated, by using WM_CHAR.

These are simple reference figures.

Current approach.

This patch.
The number of steps is increased, and the complexity of IsImeKeyEvent () is reduced.

Hi, @Yuki Hashimoto (hzuika)
Thank you for your detail writing for my easy understanding.
Excuse me, I appended in your image.

Note:

• WM_INPUT message
  • Sent to the window that is getting raw input.

• WM_CHAR message
  • Posted to the window with the keyboard focus when a WM_KEYDOWN message is translated by the TranslateMessage function. The WM_CHAR message contains the character code of the key that was pressed.

• WM_IME_STARTCOMPOSITION message
  • Sent immediately before the IME generates the composition string as a result of a keystroke. A window receives this message through its WindowProc function.

• IsImeKeyEventCandidate()
  • GHOST_ImeWin32::IsImeKeyEventCandidate()

• ImeNotHandledEventCandidate
  • GHOST_Event *ImeNotHandledEventCandidate;

For me, if "ImeNotHandledEventCandidate" rename to "evt_ImeNotHandledEventCandidate", I understand more easily.

Hi. @Harley Acheson (harley) @Yuki Hashimoto (hzuika)

I think this will make refine to avoid sensitive with a pattern of the languages.
Though, by GHOST_ImeWin32::IsImeKeyEventCandidate()'s code got simple, I can't see it what do from the code.

bool GHOST_ImeWin32::IsImeKeyEventCandidate(bool keyDown, GHOST_TKey key)
{
  if (!(IsEnglishMode()) && !(GHOST_kKeyLeftShift <= key && key <= GHOST_kKeyDownPage) && keyDown) {
    return true;
  }
  return false;
}

How about renaming IsImeKeyEventCandidate() to IsImeKeyEventCandidateToForward() for finding easily that it is a check method whether it is forward to ime?

bool GHOST_ImeWin32:: IsImeKeyEventCandidateToForward(bool keyDown, GHOST_TKey key)
{
  if (!(IsEnglishMode()) && !(GHOST_kKeyLeftShift <= key && key <= GHOST_kKeyDownPage) && keyDown) {
    return true;
  }
  return false;
}

Or, How about write the comment below at declaration of the method ( GHOST_ImeWin32.h:146 ) at the define ( GHOST_ImeWin32.cpp:82 ) too?

/* Checks a key whether IME has to do handling. */
bool IsImeKeyEventCandidate(bool keyDown, GHOST_TKey key);

/* Checks a key whether IME has to do handling. */
bool GHOST_ImeWin32::IsImeKeyEventCandidate(bool keyDown, GHOST_TKey key)
{
  if (!(IsEnglishMode()) && !(GHOST_kKeyLeftShift <= key && key <= GHOST_kKeyDownPage) && keyDown) {
    return true;
  }
  return false;
}