Hi,
Since we’ve encountered your new RadMaskedInput controls and realized, that these are the replacement of your RadMaskedTextBox (they are, aren’t they?), we didn’t find any reason for this update. Even worse, we are about to use your old RadMaskedTextBox on.
We mostly use your input controls for non-restricted text or non-restricted numeric values. In those cases we expect an input behavior like a normal TextBox got. More precisely, inputs a user enters shouldn’t replace old characters just because the mask restricts the length of the characters. The input, a user does should be just inserted at the caret’s position, without replacing.
The other problem, we’ve ran into is the following: We’ve bound a string value to the Value property of a RadMaskedTextInput control. This control has a mask of 20 optional alphanumeric characters (Mask=”a20”). Now when moving the caret at a different position then the beginning, the entered text would be saved without leading whitespaces. That’s a behavior which no user would expect.
Using your old input control, we didn’t run into all this trouble. I don’t think that there are many developers, who are used to your old Input Control, like the new ones. I don’t understand why you’ve replaced good working controls with these weak components.
I would recommend you to provide just one suite of input controls, which really work and which offers a way to be less restrictive.
Best,
Martin
4 Answers, 1 is accepted
Let me try to elaborate a bit more on our decision for creating the new suite of MaskedInput controls. The RadMaskedTextBox control works mostly with string types but there were many issues caused by the implementation of the control:
- there are numeric/currency masks which cause unexpected behavior - exceptions, incorrectly parsed value or binding issues in the MaskedTextBox control
- the RadMaskedTextBox doesn't support null values
- the RadMaskedTextBox doesn't support RegEx and the customer demand for that feature was very high
- there are issues with editing DateTime values
- the RadMaskedTextBox can't work correctly with all cultures
- the spinning behavior causes exceptions in certain scenarios
Based on our customers feedback and the growing list of issues we decided that it would be best to create a new implementation of the control. But as a MaskedInput control should work for many different inputs and apply different and very specific restrictions to each type of input, we decided to create a separate control for each type of input. This allowed us to cover most of the scenarios demanded by our customers.
And as we want to make sure that you can use the MaskedInput controls instead of the RadMaskedTextBox control to implement your requirements, your feedback is highly appreciated. Also, I want to assure you that we won't remove the RadMaskedTextBox control from our suite before making sure that our customers can replace it with the MaskedInput controls without compromising the behavior of their applications.
As for your scenarios, you are right that the MaskedInput controls allow a limited number if input characters but you can control the max number of characters and you can set a large number. For example "a99" - will create a MaskedTextInput that would allow entering up to 99 not required alphanumeric characters. And if the number is big-enough the user won't be able to fill it and it would work as per your requirements. Do you think that can work for you or am I missing something?
Also, the Value property of all MaskedInput controls keeps the value entered in the control without the formatting characters. However all controls expose a Text property which can represent the formatted Value including the placeholder characters or the formatted Value but without the placeholder characters. You can control the way the Text property is created through the TextMode property (read more). Moreover the Text property supports data binding so that you can use it to keep the formatted value in your database/business objects. In your case the Text property will keep the value and the empty positions in the MaskedInput control. And those empty positions in the Text property will be represented by the Placeholder character.
The MaskedInput controls also allow you to create custom tokens and define your own valid input - our documentation can give you a better overview of the main features and properties of the MaskedInput controls as well as a description of this scenario. And if you encounter an issue or a scenario that you need help with, just let us know and we will do our best to provide a solution.
Kind regards,
Tina Stancheva
the Telerik team
Rank 1
Hi,
Thank you for the detailed elaboration of your decision. It gives me a way better understanding why you’ve chosen the way to fully rebuild your input control suite. To be honest, we hadn’t this much trouble with the RadMaskedTextBox beside the problem that the Value Property cannot be bound to an integer value without further ado.
Now, being aware of all the issues with your RadMaskedTextBox I totally agree, that this step had to be taken. And I also agree that it’s hard to handle different types of input data with one control.
I agree that your new suite of input controls covers most of the demanded scenarios, but I think there is another highly demanded use-case which you’ve missed.
The reason why we are still using your old RadMaskedTextBox is firstly because of the MaskType propertyvalue “None”, which let the user input non-restricted text and secondly because with the RadMaskedTextBox there is a way to allow numeric input without constraining the number of digits before the decimal separator.
Your suggestion to choose a very large number of optional characters (a100) may work for a string value but for numeric values even though the value bound to the input control does not have this amount of digits the thousands separators for the unfilled digits would still appear. This wouldn't look nice at all.
Furthermore, we don’t like that approach to let the user fill a mask to enter a value in our use-case. The length of the input the user enters should be as long as the user wants. For numeric values he should be able to just enter numeric values with or without constraining the length of digits AFTER the decimal separator. For the validation of the values we decided to work with validation rules, so the input controls logic doesn’t have to mind invalid input.
Please mind our demands when updating your RadMaskedInput controls, so that we can finally replace the old RadMaskedTextBox.
Best,
Martin
Thank you for getting back to us. We will definitely keep your scenarios in mind while extending the MaskedInput controls functionality. Also there is a PITS item which you can track as its implementation will allow you to implement your scenarios out-of-the-box.
And as you mentioned the thousands separators for the unfilled digits, I just wanted to let you know that there is a property that allows you to control whether those separators should be displayed - you can find more info here.
Kind regards,
Tina Stancheva
the Telerik team
Rank 1
the problem with setting the AutoFillNumberGroupSeperators Property to False is that the numbers entered wouldn't be seperated in thousands blocks at all. But we still want this behaviour. We just don't want to have those empty thousands blocks at positions where the mask is not filled. But as you already know, we aren't using the RadMaskedNumericInput because of its mask restrictions.
I hope there will be an update soon, so that we could use your new controls.
Best,
Martin