[windows] Keyman Desktop and FLEx have trouble on 128 character boundary when editing

[mcdurdin]

Per report via mailing list.

For example, enter the string 1234567_10_234567_20_234567_30_234567_40_234567_50_234567_60_234567_70_234567_80_234567_90_23456_100_23456_110_23456_120_234567890 (130 characters long).

If I put the insertion point between the "5" and the "6" in the final copy of the string, I can type ";" + "n" to get "ŋ". And I can press backspace to get rid of that character. But if I put the insertion point between the "6" and the "7", typing ";" + "n" gives me ";n", and if I type Backspace at the end of those characters, nothing happens. I can, however, hit left arrow twice and Delete twice to get rid of those characters.

[mcdurdin]

Keyman 10.0.1055.0 and FLEx 8.3.11

[mcdurdin]

I investigated this issue on a Chiang Mai - Bangkok flight. For debug purposes, I limited the retrieval of the context from Keyman to 4 characters left of the cursor. Keyman's logging shows that with the cursor at any point between 4 and 127 characters, the 4 characters are retrieved without issue. However, when at the 128 character boundary, it fails to retrieve. Specifically, Keyman constructs a range by cloning the current selection range, then shifts it back by 4 characters. FieldWorks reports success on all these steps. Then, Keyman calls range->GetText, which succeeds but returns an empty string (and cFetched == 0), instead of the 4 characters expected.

This seems like a bug in FLEx? I cannot reproduce this problem in Word or other TSF-aware apps.

[mcdurdin]

Tested against Language Explorer 9.0.1.43235 in Baseline view, using sil_ipa keyboard attached to Icelandic locale with test string as above, typing e< between final 6 and 7 gives 6ɛ but between final 7 and 8 gives 7e<8 and then backspace also does not work. So no change in behaviour.

[mcdurdin]

@jasonleenaylor @KenZook tagging you in this as it relates to FLEx.

[marksvc]

This should be fixed in FW 9.0 built after 2018-06-22. We refined and fixed how GetText behaves, specifically to return better pacpNext and pcchPlainOut values when working with NFD.

[mcdurdin]

I tested with FW 9.0.2.43273 2018/06/22 (32 bit) and confirm that this appears resolved.