On 4/12/22 11:19 AM, Alex Kwak wrote:
Hi Jeon,
I tested your code with riched20 ( wine ver, windows ver )
It's good point. We should not write the xim ime code based on the Wine builtin richedit control.
For example, trying to type "가나" words.
following messages generated.
WM_IME_STARTCOMPOSITION GCS_COMPSTR L"\3131" GCS_COMPSTR L"\ac00" GCS_COMPSTR L"\ac04" GCS_COMPSTR L"" GCS_RESULTSTR L"\ac00" WM_IME_ENDCOMPOSITION GCS_COMPSTR L"\b098"
In the above scenario, STARTCCOMPOSITION does not occur after ENDCOMPOSITION.
in that result, "나" needs to selection. but, it isn't.
In most cases, the location of the Cursor is specified for STARTCOMPOSITION, and in ENDCOMPOSITION, the input operation is completed.
therefore, other problems arise.
OK. I agree that WM_IME_ENDCOMPOSITON should be modified.
My comment is an effort to understand the e4d94e48138f code and the situation at the time. What needs to be modified should be modified.
I think the Wine xim ime code modification should be done after [PATCH v4 1/3]. If we create code based on the XKey events rearranged by process_events(), we may have a strange patch.
Since the Wine xim ime code has been written based on the current process_events(), applying [1/3] can result in regression in some codes. But I think this is the right direction.
[PATCH v4 2/3] is currently in rework. In the process of tracking ImmSetOpenStatus(), I found that there were more fundamental problem. I think it will take time to make the appropriate patch.
[PATCH v4 3/3] is also reworking. If we actively use XFilterEvent(), Wine can generate WM_KEYDOWN message even under XIM activity.
Regards,.
Alex
On 22. 4. 11. 19:07, Byeongsik Jeon wrote:
Hi,
Actually, I don't know why.
### xim server sended event sequence ### preedit start:: preedit draw:: caret 1 chg_first 0 chg_length 0 string 'ㄱ' preedit draw:: caret 1 chg_first 0 chg_length 1 string '가' preedit draw:: caret 1 chg_first 0 chg_length 1 string '간' preedit draw:: caret 0 chg_first 0 chg_length 1 NULL preedit done:: lookup chars:: keycode 0 string 3 '가' <== HERE 1 preedit start:: <== HERE 2 preedit draw:: caret 1 chg_first 0 chg_length 0 string '나' <== HERE 3
I'm not sure, but if I guess. By "[PATCH v4 1/3]" issue, the sequence of events changes as follows:
### current Wine process_events() simulated event sequence ### preedit start:: preedit draw:: caret 1 chg_first 0 chg_length 0 string 'ㄱ' preedit draw:: caret 1 chg_first 0 chg_length 1 string '가' preedit draw:: caret 1 chg_first 0 chg_length 1 string '간' preedit draw:: caret 0 chg_first 0 chg_length 1 NULL preedit done:: preedit start:: <== HERE 4 preedit draw:: caret 1 chg_first 0 chg_length 0 string '나' <== HERE 5 lookup chars:: keycode 0 string 3 '가' <== HERE 6
IME_SetResultString() is in "HERE 6".
At this time, it is "inComp = TRUE" and WM_IME_STARTCOMPOSITION occurred. it may be thought that WM_IME_ENDCOMPOSITION is necessary.
When it and "if (!inComp) GenerateIMEMessage(imc, WM_IME_ENDCOMPOSITION, 0, 0);" combine, WM_IME_ENDCOMPOSITION come out of 'if'.
It's just guess.