Resolved the OTP Input value mismatch in ValueChanged event

[KishoreJey]

Root Cause of the Issue

In the SfOtpInput control, the GetPlaceHolder() method appends \0 (null) characters to pad the placeholder text to the required Length. These null characters unintentionally propagate into the Value property, particularly when Type is set to Number.

This behavior causes:

Value being polluted with \0 characters (e.g., "1\0\0" for Length=3)

Incorrect entry behavior: Deleting the first character shifts the second entry's value to the first, breaking the position-to-box integrity.

Description of Change

Input Type Fix (Number): Modified internal logic to prevent \0 padding from affecting the actual Value property.

Backspace Handling: Enforced a strict one-to-one mapping between value positions and UI boxes, preventing value shifting on deletion.

Value Sanitization (Optional Enhancement): Updated the Value getter to strip \0 characters before returning, ensuring a clean string representation.

Issues Fixed

Fix : #183
Prevent character shifting by maintaining strict position-to-box mapping, especially on backspace and numeric validation logic. Value Getter Enhancement (Optional): Ensure internal logic accessing Value strips \0.

Screenshots

Before:

After:

Screen.Recording.2025-06-02.154027.mp4

[Copilot]

Copilot reviewed 1 out of 1 changed files in this pull request and generated no comments.

[LeoJHarris]

Was this supposed to be resolve in 1.0.6? Because its still a problem in that version.

[naveenkumar-sanjeevirayan]

Hi @LeoJHarris
As noted in the original report, the issue was observed with the Numeric input type. We addressed this in our previous release (v1.0.6), and the fix specifically targeted the Numeric type.

However, during our internal testing, we identified that similar inconsistencies could occur with other input types as well. We’ve since implemented a broader fix to ensure the NewValue property returns a clean string across all input types, eliminating any extra null characters.

You can find the details of this fix in the following PR: #250

To help us confirm the resolution, could you please let us know:

• Are you currently using the Numeric input type in v1.0.6?
• If you’re using a different input type, does the updated fix address the issue in your scenario?

We appreciate your feedback and look forward to your confirmation.

Regards,
Naveenkumar S

[LeoJHarris]

@naveenkumar-sanjeevirayan Sorry only clearing my emails now

To help us confirm the resolution, could you please let us know:

• Are you currently using the Numeric input type in v1.0.6?
• If you’re using a different input type, does the updated fix address the issue in your scenario?

I am using as is:

<otpInput:SfOtpInput
                                    x:Name="otpTextInput"
                                    BoxHeight="48"
                                    BoxWidth="32"
                                    HorizontalOptions="Center"
                                    InputBackground="White"
                                    InputState="{Binding InputTextState}"
                                    Length="7"
                                    Stroke="DarkGray"
                                    StylingMode="Outlined"
                                    Type="Text"
                                    Value="{Binding OtpTextValue}">
                                    <otpInput:SfOtpInput.Behaviors>
                                        <toolkit:EventToCommandBehavior
                                            x:TypeArguments="otpInput:OtpInputValueChangedEventArgs"
                                            BindingContext="{Binding BindingContext, Source={x:Reference otpTextInput}, x:DataType=otpInput:SfOtpInput}"
                                            Command="{Binding OtpTextValueChangedCommand}"
                                            EventName="ValueChanged" />
                                    </otpInput:SfOtpInput.Behaviors>
                                </otpInput:SfOtpInput>asdadasdad