Hello,
I am using the numeric text box as a percentage input with a factor of 100.Typing '100' into the form field produces '100%' as expected. When I submit the form via an Ajax request, '100' is sent back to the server instead of '1'. I inspected the numeric text box element to find the value attribute is '100'. When I inspected the widget via .data('kendoNumericTextBox') the value is '1'.
Is this expected? Shouldn't Kendo make sure the value attribute on the element is the same value as the widget?
Thanks
11 Answers, 1 is accepted
Thank you for describing the specific scenario.
I made an example and the value of the widget is 1 when the percentage is 100:
http://dojo.telerik.com/eluQI
Please advise if I missed an important detail.
Regards,
Stefan
Progress Telerik
Hi,
This is what you need to reproduce the issue. In your example, change the numeric text box code to:
$("#numerictextbox").kendoNumericTextBox({
format: "p0",
min: 0,
step: 0.01,
factor: 100
});
Repro Steps:
1. Type 10 into the percent input. It should change to 10%.
2. Inspect the element and notice the input element's value attribute is "10"
Expected Result:
The value attribute should be 0.1 (.1 = 10%)
When a form is submitted it takes the value attribute "10", but the desired value should be ".1".
I used the provided configuration, placed it in the Dojo example and the value of the widget is 0.1 as expected.
http://dojo.telerik.com/eluQI/3
If the issue is with the aria-valuenow attribute, please advise, as this is used for the screen readers, where if the user knows that this is %, it is expected to read the percent value. If this is not expected based on the Aria attributes specification, please let us know and we will investigate it.
Regards,
Stefan
Progress Telerik
I realize this is pretty old but I think Brian is right, although maybe this is by design. In your Dojo example, you're using the control's value but the value of the actual input element is not the same (it uses the display not the factored).
http://dojo.telerik.com/OQaMEQuY
So in your example you just manually retrieved the control's value which is 0.1, but if you actually posted the form that you created it would POST a value of 10.
IF anyone else needs it, I got it to work by using the Kendo NumericTextBox as a proxy. I loaded the kendo control, then took the 'name' attribute that was applied to it and created a new hidden input that stores the real value. When the kendo control changes I update the hidden input field so that posting the form takes the proper value instead of the formatted value.
Code sample below accomplishes this for all inputs on a form that are ".percent"...
$(".percent").each(function (i, percentElement) {
percentElement = $(percentElement);
var control = percentElement.kendoNumericTextBox({
format: "p",
step: 0.01,
factor: 100,
decimals: 4
}).data('kendoNumericTextBox');
$('<input type="hidden" class="k-numerictextbox-fix" />')
.attr('name', percentElement.attr('name'))
.appendTo(control.wrapper)
.data('kendoNumericTextBox', control);
percentElement.attr('name', null);
control.bind('change', function (e) {
// The value of the control is correct (0.1 for 10%),
// but the value of the HTML input is incorrect (10 for 10%).
// So on change, manually edit the HTML input value
e.sender.wrapper.find('.k-numerictextbox-fix').val(e.sender.value());
});
});
@Kevin, I just ran into this as well. The NumericTextBox instance has the correct .value() of "0.1", but the textbox input itself has the value "10", and that "10" is what gets POSTed to the server with the form. This surely cannot be by design. What's the point of the underlying NumericTextBox instance having a different value than the input, if the input's value is the only one getting sent to the server?
Can a Telerik rep confirm this is by design please?
Hello John,
Can you send us a very basic dojo sample to demonstrate the mentioned behavior so I can forward it to our Dev team for deeper insight?
Regards,
Eyup
Progress Telerik
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Eyup,
You can access http://dojo.telerik.com/eziWUWEh to see what we're talking about here. If you enter, say, "50" in the NumericTextBox, the NumericTextBox value is correctly ".5", as you will see in the Console, but the value of the textbox will remain "50", and the "50" is what gets sent along with the form. So again, the question is: what is the purpose of Kendo being able to retain an underlying value of ".5" if that value doesn't get sent along with the form? Totally defeats the purpose, from what I can tell
The intention here is to use the Kendo NumericTextBox to have the underlying value always be in decimal form, but the NumericTextBox show the underlying value in a specifically-formatted way. I'm shocked this hasn't been brought up more often.
Hello John,
Thank you for the clarification.
I can now see what you have in mind and I can observe the described behavior.
After further research, I found out that this is caused by the factor setting:
https://docs.telerik.com/kendo-ui/api/javascript/ui/numerictextbox/configuration/factor
When it is set, "the obtained result is used as edit value." It is designed this way and changing it will rather bring unwanted breaking changes.
Do you think we can find another acceptable way for your scenario? To achieve a similar functionality using a different approach? Could you share additional info on the bigger picture?
Regards,
Eyup
Progress Telerik
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Again, I would ask, what is the purpose of the NumericTextBox having an underlying value (.5) AND a visual value (50), if only one is ever used? That's great that the NumericTextBox allows a different, factored underlying value, but what is the purpose if it isn't sent to the server?
In my case, I do need different values, as it's user friendly to have the user enter a percentage (50) . . . then it saves some work to have a different underlying value (.5) sent to the server. But that's not how this widget works. So I'm just trying to understand why it works the way it works now.
Obviously, it would be possible to attach to the change event of the NumericTextBox and update a hidden input with the same name, but that's an extra step that shouldn't be necessary. If I'm misunderstanding the purpose or use of the different values, feel free to let me know what I'm missing. Thank you.
Hello John,
I think I agree with you. I will log this as an improvement idea in our public portal. I am afraid it won't be suitable to change the behavior without property since this could be a breaking change to many users.
Thank you for reporting this and sharing your thoughts. I have updated your Telerik Points as a token of gratitude.
Regards,
Eyup
Progress Telerik
Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.
Hi Lee,
I will check up on this and will get back to you tomorrow.
Regards,
Nikolay
Hi Lee,
Yeah, I am afraid this is still not implemented as it didn't make it to our priority list.
Can you share additional details on your specific scenario? I am willing to help you come up with a working solution tailored for your exact project.
I am afraid not:
https://feedback.telerik.com/kendo-jquery-ui/1509201-copy-paste-in-numerictextbox-with-factor-property-outputs-wrong-number
I offer you a complimentary Remote Assistance Meeting where we can discuss this matter live. Can you tell me when you are available this week and the Time Zone and the City you are living in so I can organize the meeting? We can then discuss what solution we can for your specific case.