It seems IME will make things worse. If use english layout, It seems OK .

If you add information about the type of IME (Microsoft IME?, Google IME?) and the language (Chinese? Japanese? Korean?), it will be easier to reproduce the problem.

@Takahiro Shizuki (sntulix) Do you know the cause of that bug?

Hi. @Yuki Hashimoto (hzuika)

I don’t know it yet.

By the way, I will do a task (https://developer.blender.org/T93421#1264170).
It’s approach may be not conflict with here, but I tell it as FYI.

I reproduce this with Microsoft Chinese IME, maybe.

a reproducing capture by ffmpeg. (ffmpeg.exe -offset_x 1360 -offset_y 0 -video_size 1200x1600 -framerate 30 -f gdigrab -i desktop -vcodec libx264 -pix_fmt yuv420p desktop.mp4)

"." key's define in windows: code 190, 0xBE, VK_OEM_PERIOD "." key [.>]

Hi.

I am checking this.

About . key code in Microsoft IME Pinyin.

Case when inputting . key,

• This has START, END of COMPOSITION event.
• This has no problem.

Case when inputting 0 . 0 keys,

• This has no COMPOSITION event.
• This is expected to be "0.0", but "00".

Shoud I do modify the function of handling Chinese letters at GHOST_ImeWin32::IsImeKeyEvent() like below?

diff --git a/intern/ghost/intern/GHOST_ImeWin32.cpp b/intern/ghost/intern/GHOST_ImeWin32.cpp
index d1fc80adf56..78c441ceb28 100644
--- a/intern/ghost/intern/GHOST_ImeWin32.cpp
+++ b/intern/ghost/intern/GHOST_ImeWin32.cpp
@@ -98,24 +98,34 @@ bool GHOST_ImeWin32::IsEnglishMode()

 bool GHOST_ImeWin32::IsImeKeyEvent(char ascii)
 {
   if (!(IsEnglishMode())) {
     /* In Chinese, Japanese, Korean, all alpha keys are processed by IME. */
     if ((ascii >= 'A' && ascii <= 'Z') || (ascii >= 'a' && ascii <= 'z')) {
       return true;
     }
     if (IsLanguage(IMELANG_JAPANESE) && (ascii >= ' ' && ascii <= '~')) {
       return true;
     }
     else if (IsLanguage(IMELANG_CHINESE) && ascii && strchr("!\"$'(),.:;<>?[\\]^_`/", ascii)) {
+      switch (ascii) {
+        case '.':
+        /*
+        * check if IME is not in COMPOSITION by some way.
+        */
+        return false; /* This makes key handling with GHOST and print '.' letter. */
+
+        default:
+          break;
+      }
       return true;
     }
   }
   return false;
 }

@Takahiro Shizuki (sntulix), it takes someone with experience in this to review the suggested change (if you're sure it's safe, i think we can skip the review).
I suggest creating a patch through https://developer.blender.org/differential/diff/create/ and contacting one of the developers who worked in the area (Eg. https://developer.blender.org/diffusion/B/history/master/intern/ghost/intern/GHOST_ImeWin32.cpp).

This is just a wild guess, but is it possible that this IME is converting the keypress of the period key to Chinese full stop (U+3002 ideographic full stop)? This is a period that is the same width as other characters. If this is the case we could probably treat that as a regular decimal in the numeric input code.

Edit - No. But it is a little odd

When in English I get both a KM_PRESS and KM_RELEASE of EVT_PADPERIOD. But in Chinese I am seeing only KM_RELEASE of EVT_PADPERIOD and not the KM_PRESS we act on.

@Takahiro Shizuki (sntulix) - I am seeing proper behavior in number input while in Pinyin if I remove decimal from your list of IsImeKeyEvent, like this:

diff --git a/intern/ghost/intern/GHOST_ImeWin32.cpp b/intern/ghost/intern/GHOST_ImeWin32.cpp
index d1fc80adf56..b2ef0023099 100644
--- a/intern/ghost/intern/GHOST_ImeWin32.cpp
+++ b/intern/ghost/intern/GHOST_ImeWin32.cpp
@@ -106,7 +106,7 @@ bool GHOST_ImeWin32::IsImeKeyEvent(char ascii)
     if (IsLanguage(IMELANG_JAPANESE) && (ascii >= ' ' && ascii <= '~')) {
       return true;
     }
-    else if (IsLanguage(IMELANG_CHINESE) && ascii && strchr("!\"$'(),.:;<>?[\\]^_`/", ascii)) {
+    else if (IsLanguage(IMELANG_CHINESE) && ascii && strchr("!\"$'(),:;<>?[\\]^_`/", ascii)) {
       return true;
     }
   }

One complication is that there are two different keys that can enter "." in a numerical input (the one among regular keys and the one in the numerical keypad).

With current code I can press the regular period key to enter that character in text inputs to enter a wide Chinese period - "。" into text inputs. That seems fine as I can enter a regular period in English mode? But I can't enter a decimal point into a numerical entry with either key. With regular key it enters a wide period that is not accepted as valid, while numpad key does not register (I get KM_RELEASE but no KM_PRESS).

With above change I can enter decimals into numerical entries with either key. But I can duplicated characters when entering into a text input like this ".。". This might be a compromise you find is okay.

An alternative is to pass the GHOST_TKey to IsImeKeyEvent, take "." out of that test and add an "||" for key == GHOST_kKeyPeriod. That way it is for GHOST_kKeyPeriod but not for GHOST_kKeyNumpadPeriod.

With this you can enter decimal into numerical entries with numpad decimal, and you get wide period with regular key in text inputs. The only limitation is unable to enter decimal into numerical inputs with the regular period key. Again, might be a compromise you are okay with since you can toggle to English mode.

So far not seeing any nicer solution. It would be weird to change a "。" to a "." within ui_do_but_textedit at WM_IME_COMPOSITE_EVENT. ie: check ime_data->str_result against 0xE3 0x80 0x82 and insert a "." instead if ELEM(but->type, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER) but would work in theory.

In T93626#1286354, @Germano Cavalcante (mano-wii) wrote:

@Takahiro Shizuki (sntulix), it takes someone with experience in this to review the suggested change (if you're sure it's safe, i think we can skip the review).
I suggest creating a patch through https://developer.blender.org/differential/diff/create/ and contacting one of the developers who worked in the area (Eg. https://developer.blender.org/diffusion/B/history/master/intern/ghost/intern/GHOST_ImeWin32.cpp).

I'll do it. There are also other many peoples!! Thank you.

In T93626#1286426, @Harley Acheson (harley) wrote:

@Takahiro Shizuki (sntulix) - I am seeing proper behavior in number input while in Pinyin if I remove decimal from your list of IsImeKeyEvent, like this:

: )

Hi.

I found a icon Chinese/English punctuation in Microsoft IME PinYin.

It's status value can get by ImmGetConversionStatus().

- Microsoft Chinese IME Pinyin input pattern (conversion mode)
  - English (Half/Full, English punctuation only)
    - English Half width (1 IME_CMODE_NATIVE)
    - English Full width (8 IME_CMODE_FULLSHAPE)
  - Chinese (Half/Full, Chinese/English punctuation)
    - Chinese Half width, English punctuation (1 IME_CMODE_NATIVE?)
    - Chinese Half width, Chinese punctuation (401 IME_CMODE_SYMBOL | IME_CMODE_CHINESE)
    - Chinese Full width, English punctuation (9 IME_CMODE_CHINESE | IME_CMODE_FULLSHAPE)
    - Chinese Full width, Chinese punctuation (409 IME_CMODE_SYMBOL | IME_CMODE_CHINESE | IME_CMODE_FULLSHAPE)

But when input "0.0", the conversion status was not changed.

This is just think that Microsoft IME PinYin has numeric mode status. Maybe, he is changed by the key "0-9" to English punctuation, and it ends by the key not "0-9" and swich to Chinese punctuation.
I'll find about this.

Although, This task may be fix by creating a status property of punctuation language at GHOST_ImeWin32.

edit

By the way, I found that when input 0 with Fullwidth in Microsoft IME PinYin's Fullwidth mode, I got "0０". -> T94868

FYI

ime_cmodes.h
// bit field for conversion mode
#define IME_CMODE_ALPHANUMERIC          0x0000
#define IME_CMODE_NATIVE                0x0001
#define IME_CMODE_CHINESE               IME_CMODE_NATIVE
#define IME_CMODE_HANGUL                IME_CMODE_NATIVE
#define IME_CMODE_JAPANESE              IME_CMODE_NATIVE
#define IME_CMODE_KATAKANA              0x0002  // only effect under IME_CMODE_NATIVE
#define IME_CMODE_LANGUAGE              0x0003
#define IME_CMODE_FULLSHAPE             0x0008
#define IME_CMODE_ROMAN                 0x0010
#define IME_CMODE_CHARCODE              0x0020
#define IME_CMODE_HANJACONVERT          0x0040
#define IME_CMODE_NATIVESYMBOL          0x0080


imm.h
// bit field for conversion mode
// IME_CMODE_HANGEUL is old name of IME_CMODE_HANGUL. It will be gone eventually.
#define IME_CMODE_HANGEUL               IME_CMODE_NATIVE
#define IME_CMODE_SOFTKBD               0x0080
#define IME_CMODE_NOCONVERSION          0x0100
#define IME_CMODE_EUDC                  0x0200
#define IME_CMODE_SYMBOL                0x0400
#define IME_CMODE_FIXED                 0x0800
#define IME_CMODE_RESERVED          0xF0000000

// bit field for sentence mode
#define IME_SMODE_NONE                  0x0000
#define IME_SMODE_PLAURALCLAUSE         0x0001
#define IME_SMODE_SINGLECONVERT         0x0002
#define IME_SMODE_AUTOMATIC             0x0004
#define IME_SMODE_PHRASEPREDICT         0x0008
#define IME_SMODE_CONVERSATION          0x0010
#define IME_SMODE_RESERVED          0x0000F000

In T93626#1286499, @Harley Acheson (harley) wrote:

So far not seeing any nicer solution. It would be weird to change a "。" to a "." within ui_do_but_textedit at WM_IME_COMPOSITE_EVENT. ie: check ime_data->str_result against 0xE3 0x80 0x82 and insert a "." instead if ELEM(but->type, UI_BTYPE_NUM, UI_BTYPE_NUM_SLIDER) but would work in theory.

If it is true that Microsoft IME PinyYin has numeric mode and if ime_data->str_result gets always each key press, you may get that pressing . is 'period' or 'fullstop' by check last character of ime_data->str_result.

The following is the minimum changes I could find to fix this:

The change to IsImeKeyEvent is needed to allow numpad decimal entry. The change to ui_do_but_textedit allows using Chinese full stop as decimal. So this allows both keys to enter "." into a number, while still allowing entry of "。" into text fields.

Hi. @Harley Acheson (harley)

IMEDecimal.diff10 KBDownload

The change to IsImeKeyEvent is needed to allow numpad decimal entry. The change to ui_do_but_textedit allows using Chinese full stop as decimal. So this allows both keys to enter "." into a number, while still allowing entry of "。" into text fields.

I checked. It's good.

checked list

• object properties
  • Location X
    • Microsoft IME Pinyin
      • Numpad's key 0-9 . - + * /
      • Numpad's key "0.1+1" -> 1.1m.
    • Microsoft IME Pinyin (compatible)
      • Numpad's key 0-9 . - + * /
      • Numpad's key "0.1+1" -> 1.1m.

Okay, I think we’ll have to do this slightly differently. I’ll probably submit this as two separate patches because there are two quite different things here that should be considered separately. And I’ll probably make you, @Takahiro Shizuki (sntulix), one of the reviewers.