Input Method Editor events for TextBox

[maxkatz6]

https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.textbox.textcompositionchanged?view=winrt-20348 https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.textbox.textcompositionended?view=winrt-20348 https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.textbox.textcompositionstarted?view=winrt-20348

Text composition events occur in the following order:

• TextCompositionStarted
• TextChanging
• TextChanged (can be replaced with PropertyChanged event right now, see https://github.com/AvaloniaUI/Avalonia/issues/418)
• TextCompositionChanged
• TextCompositionEnded

After the TextCompositionStarted event, the TextChanging > TextChanged > TextCompositionChanged event cycle can occur multiple times before the TextCompositionEnded event occurs.

[kekekeks]

I'm not sure how well that would play with iOS IME API. Or any non-windows IME API.

There is a common concept of non-commited (preedit) text that's displayed after the current caret. Said text is ephemeral and shouldn't be passed to the application until the input method tells us to do so.

iOS might also want us to change arbitrary chunks of text for its auto-correction system to work properly.

[robloo]

TextChanged

Implement TextChanged event for TextBox #418

[robloo]

@maxkatz6 @kekekeks @danwalmsley What is the latest thinking for this issue? I'm going to need these sorts of events soon.

If there are no objections/roadblocks I will plan to implement at least TextChanged. That is required for a number of cases on my end and is very helpful if there is no binding being done. If TextChanging doesn't look too complicated I might attempt that as well.

[kekekeks]

It should be OK to have TextChanged/TextChanging as long as they don't see any uncommited text. Makes implementation more straightforward too.