We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Maskedit doesn't accept leading zeros

Thread ID:





150607 Jan 13,2020 12:56 PM UTC Jan 17,2020 08:55 AM UTC Xamarin.Forms 3
Tags: SfMaskedEdit
Asked On January 13, 2020 12:56 PM UTC

I'm using SfMaskedEdit control in order to accept OTP entry. I have following code :
<sfMaskedEdit:SfMaskedEdit Mask="0  0  0  0  0  0" BackgroundColor="Transparent" x:Name="otpEntry" Value="{Binding OTPValue}" ValidationMode="KeyPress" 
    ValueMaskFormat="ExcludePromptAndLiterals" Keyboard="Numeric"/>
It doesn't accept the leading Zero (0) e.g. if my generated otp is 049271 then it doesn't allow me to enter leading zero and I end up entering 49271 only (instead of leading zero). Is there any setting which will allow me to accept leading zeros as well?


Ramya Soundar Rajan [Syncfusion]
Replied On January 14, 2020 07:25 AM UTC

Hi Krunal, 
Thanks for contacting Syncfusion support. 
We have tried to replicate the reported issue at our end, but we are afraid that we are not able to reproduce the issue at our end. We have set default value of the binding property and checked the mask value as per your provided value.  Please find the sample from the following location. 
Output Screenshot: 
We have checked with the below configuration  
Android Device: Samsung s8 plus 
Syncfusion Version: 
Xamarin Forms Version: 
Please share the replication steps like short video and configuration details, etc. This would be helpful for us to give better solution in this.  

Replied On January 15, 2020 12:33 PM UTC

In my viewmodel, OTP property was of type Nullable<int>. Once I changed it to string it started accepting the leading zeros.

Vignesh Ramesh [Syncfusion]
Replied On January 17, 2020 08:55 AM UTC

Hi Krunal, 

Thanks for your response. 

We would like to inform that, it is the default behavior of integer type. If we assign 01 or 1, it is considered as 1. So, you are facing the reported problem. Also, we have cross-checked this by binding the same value with Entry. It also provided the same result. You can avoid this problem by using string type property as we have provided in our previous update sample. 



This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Please sign in to access our forum

This page will automatically be redirected to the sign-in page in 10 seconds.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon

Live Chat Icon For mobile
Live Chat Icon