imm32: When IME composition is done, send WM_IME_COMPOSITION for the composition text before sending it for the result text
From: Masahito S firelzrd@gmail.com
--- dlls/imm32/ime.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/dlls/imm32/ime.c b/dlls/imm32/ime.c index fa8e94acb21..d58733ab210 100644 --- a/dlls/imm32/ime.c +++ b/dlls/imm32/ime.c @@ -557,14 +557,6 @@ UINT WINAPI ImeToAsciiEx( UINT vkey, UINT vsc, BYTE *state, TRANSMSGLIST *msgs, TRANSMSG status_msg = {.message = ime_set_composition_status( himc, !!compstr->dwCompStrOffset )}; if (status_msg.message) msgs->TransMsg[count++] = status_msg;
- if (compstr->dwResultStrLen) - { - const WCHAR *result = (WCHAR *)((BYTE *)compstr + compstr->dwResultStrOffset); - TRANSMSG msg = {.message = WM_IME_COMPOSITION, .wParam = result[0], .lParam = GCS_RESULTSTR}; - if (compstr->dwResultClauseOffset) msg.lParam |= GCS_RESULTCLAUSE; - msgs->TransMsg[count++] = msg; - } - if (compstr->dwCompStrLen) { const WCHAR *comp = (WCHAR *)((BYTE *)compstr + compstr->dwCompStrOffset); @@ -574,6 +566,14 @@ UINT WINAPI ImeToAsciiEx( UINT vkey, UINT vsc, BYTE *state, TRANSMSGLIST *msgs, else msg.lParam |= CS_INSERTCHAR|CS_NOMOVECARET; msgs->TransMsg[count++] = msg; } + + if (compstr->dwResultStrLen) + { + const WCHAR *result = (WCHAR *)((BYTE *)compstr + compstr->dwResultStrOffset); + TRANSMSG msg = {.message = WM_IME_COMPOSITION, .wParam = result[0], .lParam = GCS_RESULTSTR}; + if (compstr->dwResultClauseOffset) msg.lParam |= GCS_RESULTCLAUSE; + msgs->TransMsg[count++] = msg; + } }
ImmUnlockIMCC( ctx->hCompStr );
Related Bugzilla: Microsoft Office: IME result string may get doubled when edit is done https://bugs.winehq.org/show_bug.cgi?id=55027
Sadly this will break some specific sequences (Japanese NIHONGO-NO, or Korean GA-NA-DA) as described in https://gitlab.winehq.org/wine/wine/-/merge_requests/2637 and https://gitlab.winehq.org/wine/wine/-/merge_requests/2749.
The sequences work with a result string committed at the same time as, or shortly before, a new composition string is provided, beginning the next composition. We need to report the result string first, and then the new composition string.
I still think this is a case where XIM sequence is broken, and where we send the IME updates in the wrong order. I updated https://gitlab.winehq.org/wine/wine/-/merge_requests/2698 with a better fix, to fix the event order and avoid reporting the previous composition string when the result string is committed (which was missing before).
This merge request was closed by Masahito Suzuki.
Thank you for your time and review!