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;
}

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

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

I did test some case.

I just looked, it seems that is ok. But I will test some case later.

Are you able to give some more information on what is the expected behavior and use case for this?

I don't expect a something about this. Because I'm not a End User of Chinese Language.
Also this is a just reporting I found.

In D13902#370996, @Harley Acheson (harley) wrote:

In D13902#370995, @Takahiro Shizuki (sntulix) wrote:

(updated.)

I’m not Chinese IME User, so I can’t review about converting “ 。” to “.”.

No problem. You are always so helpful. What languages do you use?

I’m not Chinese IME User, so I can’t review about converting “ 。” to “.”.

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.

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

I seem that this is similar with T93421. And it will be fix by D13551.
Could you find it is similar with it?

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

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

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:

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 am checking this.

---

Ah, I can confirm this now, I'm OK because I enable this before:

In T94434#1279546, @Harley Acheson (harley) wrote:

I may be found the point to fix.

I confirmed reproducing this problem with Blender 2.93.3 and both Microsoft Chinese Pinyin and Microsoft ChangJie and its had been fixed by D11929 (v3.0 alpha).

I see.

In T91103#1276243, @Richard Antalik (ISS) wrote:

In T91103#1273544, @Takahiro Shizuki (sntulix) wrote:

I can't reproduce "J輸O入L中Y文J字" with Blender 2.93.3 and Japanese keyboard. But I think it was fixed with D11929.

I think this is confirmed. And close please.

Sorry I am not sure if I understand, do you mean this is resolved already?

In T91103#1218963, @炎臻 (PrettyFireNOI7) wrote:

Well I just tested in 3.0 alpha, all the things are good,former one is in 2.93.4.

I reproduced with Blender 3.0.0 alpha at September 18. And I confirm that it is not happend with T93421's triaging build binary (https://developer.blender.org/T93421#1268780).
So I think it is same with T93421 and will be fixed at D13551.

This was fixed at D11929. So close here, please.

Since only numbers will be inputted in numeric text editing.

Sorry, This is the task, not differental. I close here.

Thank you for watching the task about IME.
By the way, I posted D13551 without closing here, can I close here?

In T93421#1269610, @炎臻 (PrettyFireNOI7) wrote:

@Takahiro Shizuki (sntulix) Hi, I have tested the new build in Chinese, Korean, Japanese.

• One bug, when using Chinese IME, the input / outputs "/、“ :
  
  ,which should be ”、“ :
  
  There is a redundant "/".

I built a binary that I'm working on.
https://www.futuregadget.com/file/Blender-master-3.1.0-T93421-working_on.zip

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)

I reproduce this with Microsoft Chinese IME, maybe.

I don’t know it yet.

Hi.
Thank you for your concern. @炎臻 (PrettyFireNOI7)

Thank you for your work @炎臻 (PrettyFireNOI7)

ui_textedit_end() {
...
#ifdef WITH_INPUT_IME
  ui_textedit_ime_end(win, but);
#endif
}

I confirmed with Microsoft IME Chinese pinyin that IME end when clicking 3D viewport after no inputting to a text edit box.

I think if the IME auto-switching is functional, after switching to other programs, IME's mode should be automatically set back to Japanese so it is able to input Japanese and write commentary (I don't know what plate is). Then after switching back to Blender, the mode would be automatically set to English. Also as my testing (Windows,daily 3.0), this is currently what IME auto-switching is doing in Blender but I don't know if this behavior is consistent for other Windows user.

I found Blender calls a IME End function when exit a text edit box by clicking. But it doesn't call the function when no IME input currently.
It's below:

• source file: source\blender\editors\interface\interface_handlers.c

ui_textedit_end() {
...
#ifdef WITH_INPUT_IME
  if (win->ime_data) {
    ui_textedit_ime_end(win, but);
  }
#endif
}

Thank you for confirm on previous task and comming new task.

In T92410#1260770, @Richard Antalik (ISS) wrote:

I am not sure if I understand what current status is, I saw one comment that this is not resolved, but with no updated steps.

I do reproduce a similary malfunction everytime with the exact step at this page's description by a few different way.

Exact steps for others to reproduce the error
(Steps may need tweaking with different setup)

I found another bug that blender crash when the the manupilation repeatly that doing typing in text box and swtching from text box to 3d viewport with keep IME word convertioning list box and back to text box and type again, though I don't know it has releation with this malfunction.

In T92410#1259274, @NXSK (NXSK) wrote:

I can't reproduce with Microsoft IME installed Japanese, English and Chinese Pinyin but I build a Blender binary from master branch with debug prints about Input event and IME status to system console.
https://www.futuregadget.com/file/Blender-T92410-Debug.zip

This patch consists of just a single line change: calling UpdateConversionStatus in WM_IME_SETCONTEXT handler. This simple change appears to fix the problem and seems quite harmless, since this is only on the window gaining focus.

A proposal to rename "UpdateConversionStatus" to "UpdateConversionModes" would need to be a separate patch submission. Although not sure I would support that refactor. The function gets "modes" but it is a wrapper for "ImmGetConversionStatus" so I'd prefer the names to match as that makes it easier to understand for others who are familiar with the IME API.

add below in WM_IME_SETCONTEXT event in GHOST_SystemWin32::s_wndProc()

ime->UpdateConversionStatus();

I finished.
Would you review, please?

In T92410#1252637, @Zijun Zhou (Eary) wrote:

@Takahiro Shizuki (sntulix) Do you know what's going on? I am tagging you because you were the author of the patch D11929 that I suspect might be related.

I fixed this :)

In D12848#346656, @Harley Acheson (harley) wrote:

@Takahiro Shizuki (sntulix) - I made a patch about this with minimum changes and no duplication codes.

Interesting!

I think this is functionally equivalent but with less changes and it might be easier to follow?

IMEDup.diff35 KBDownload

I made a patch about this with minimum changes and no duplication codes.

Here’s a quick update that ImmGetContext() return 0 at WA_ACTIVE.
It is happen when switched to main window after a new window closed with IME off.

added checking WA_CLICKACTIVE when switching between windows by mouse click.

In D12848#344269, @Harley Acheson (harley) wrote:

I've never liked that else as I'd rather leave things alone when in an unknown state rather than clear them. We already initialize those variables to those values on window creation, so there should be no good reason to set them to that when we are without imm_context. And when I breakpoint that else I only ever see the default values being assigned to those variables, and they already have those values.

I checked the a bug and fixed.
Watch please.

I need some feedbacks. but are you on BCon in all time?

In D12848#337304, @Takahiro Shizuki (sntulix) wrote:

• add GHOST_ImeWin32::SaveConversionStatus(hwnd).

• add GHOST_ImeWin32::SaveConversionStatus(hwnd).
• fixed to avoid needless reset IME status with initial value by failing ImmGetContext() after creating new window.

@Richard Antalik (ISS) Thank you.

Thank you for your looking.

I found Dialog Window (Save Dialog etc) has this bug yet.
May be, Dialog window's window procedure is separated from main window's. So we have to call setting IME status per window and dialog.