InputView with TextTransform="Uppercase" triggers TextChanged twice per character

[bhavanesh2001]

Description

When using <Entry TextTransform="Uppercase" />, typing a lowercase character causes the TextChanged event to fire twice:

1. Once with the raw lowercase input (e.g., "d")
2. Again with the transformed uppercase result (e.g., "D")

Happens with Entry, Editor, SearchBar

Steps to Reproduce

No response

Link to public reproduction project repository

https://github.com/bhavanesh2001/maui-bugs/tree/text_changed_bug

Version with bug

9.0.70 SR7

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

iOS, Android, Windows, macOS

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

[deepika2509]

This issue has been verified in Visual Studio 17.14.0 Preview 4.0 for windows and Visual Studio Code 1.99.3 with MAUI versions (9.0.0, 9.0.80 & 8.0.100). It can be reproduced on Windows, Android, iOS and macOS platforms.

[mattleibow]

Yeah, this is unfortunately the way it works because the text transform is a post processing step. When the text changes, the change is checked to see if it needs to transform and the resets the text to upper case.

The system does not intercept, nor do I think you can.

All solutions I have seen are watching the changes and re-applying text.

[bhavanesh2001]

@mattleibow Yeah, this is something I found while working on #29970. If I stop the round trip for Text, then TextTransform stops working.

I don’t really understand the TextTransform API. If there’s no out-of-the-box support for this on any platform, why are we taking on the extra burden of supporting it ourselves?

If a user really wants TextTransform, they can easily implement it themselves.

[mattleibow]

Now you are asking the right questions. 😎 The answer? Because it was cool to do x years ago and we can't remove it. 😭

But, maybe this is an idea to obsolete @jfversluis @PureWeen?

I wonder if we should rather be exposing a WillUpdateText type event and use that. Since we control the Xaml layer, we may be able to detect things.

But, not sure.

In the end, someone asked before and here we are with all sorts of complicated features. It probably needs to be design properly and not tacked on.

I think we do the same for max length. We set and then delete. We really need a real system to intercept.