When calling setOptions on the numericTextBox, the spinner locks up if there is a "factor" option set.
https://dojo.telerik.com/OYiYogis
See the above Dojo.
Removing the factor seems to fix the issue, but I need the factor so that a user can type in 10 for 10% when the type is percentage but 10 for $10.00 when the type is currency.
Bug report
Since R1 2022 spin event is no longer triggered when setOptions is called in NumericTextBox
Reproduction of the problem
Dojo: https://dojo.telerik.com/eTAfAyuP
Expected/desired behavior
Spin event shall fire after setOptions() is called.
Environment
Kendo UI version: 2022.1.119 or above
jQuery version: All
Browser: All
https://docs.telerik.com/kendo-ui/api/javascript/ui/numerictextbox/configuration/decimals
It claims that when you are accepting two decimals, entering 12.99 will get rounded to 13.00. this doesn't happen and would be wrong if it did.
### Bug report
When the Kendo UI NumericTextBox has the factor property set and a value pasted, a wrong number is output.
### Reproduction of the problem
1. Create a NumericTextBox and set the format and factor properties.
2. Set a value. Copy and paste value greater than 1.
3. The value 100 is applied to the widget.
Dojo sample for reproduction:
https://dojo.telerik.com/ufOSEGEn
### Expected/desired behavior
The pasted value should be applied to the widget.
### Environment
* **Kendo UI version:** 2021.1.224
* **jQuery version:** 1.12.4
* **Browser:** [all]
### Bug report
NumericTextBox cannot be initialized when element with id options is present on the page. For instance, a div element with id="options".
### Reproduction of the problem
1. Create a NumericTextBox.
2. Add an element with id options.
Dojo sample for reproduction:
https://dojo.telerik.com/oWIwUSAp
### TicketID: 1562966
### Environment
* **Kendo UI version:** 202x.r.ddd
* **jQuery version:** x.y
* **Browser:** [all]
Bug report
The pasted value containing whitespaces into numeric textbox results in a trimmed value
Reproduction of the problem
Open this example: https://dojo.telerik.com/iTiBArEh
Click "Run"
Paste "1 000" into the NumericTextBox
Expected/desired behavior
The pasted value shall be '1000' instead of '1'
Environment
Kendo UI version: 2021.2.616 and above
Browser: [all]
Currently, if a user enters into a numeric text box a value that is lower than the "min" or greater than the "max" configuration option, kendo adjusts the value to either min or max.
There should be a way to disable that. If the user enters an invalid value we want to give feedback. Currently, there is no way to do this, without messing around with the kendo ui control.
By the way: kendo ui for angular has already implemented an autoCorrect configuration. So please implement this feature for the jquery version too!
Please consider supporting entry of values in exponential notation (with 'e' or 'E') so that the behaviour is similar to a native <input type="number> element.
Kendo formatters allow display in scientific notation, but prevents data input in this form.
Currently if k-min is set to 100 and a value less than 100 is entered the control will automatically change the value to 100. This is very poor behavior. User input should NEVER be automatically changed to another value. The users rarely notice this and it leads to incorrect data being stored. What should happen is that it should raise a validation error. Further it should support using Angular validation for these errors.
Currently, NumericTextBox pops up the standard keyboard on tablet/mobile devices.
So for a user who is entering numbers in multiple fields this can get tedious having to constantly change keyboards.
Since this is a numeric entry control my suggestion is that a numeric keyboard is used.
Related to #1515708
Bug report
The kendo.parseFloat() method does not correctly parse negative currency strings in which the currency symbol is placed before the actual value i.e. "$ -5.00".
Reproduction of the problem
1. Set the culture of the app to nl-NL (or another that formats the currency as $ -5.00)
2. Call the parseFloat method.
3. The value "null" is returned.
Dojo sample for reproduction https://dojo.telerik.com/AFOnaQIt
Current behavior
The kendo.parseFloat() method assumes that all negative currency values are in the format "-5.00 $". Since the format of the nl-NL culture has the format "$ -5.00, the if-clause that checks the position of the "-" fails, and the method returns null.
Expected/desired behavior
Negative values with any currency format should be parsed correctly.
Environment
* **Kendo UI version:** 2021.1.224
* **jQuery version:** 1.12.4
* **Browser:** [all]
Feature enhancement
NumericTextBox pops keyboard on mobile on scroll
Reproduction of the problem
https://dojo.telerik.com/uFUNEboh
1. Open up https://runner.telerik.io/fullscreen/uFUNEboh on a cellphone (We've tested with real Android devices)2. Touch a NumericTextBox so the keyboard pop once (this step is not required on our end for some reason)
3. Touch outside the keyboard to close it
4. Start scrolling up and down, but starting a drag from a NumericTextBox or touch one when scrolling
5. Notice the keyboard pops open when it should not close it and continues to scroll, it will reopen again and again.
Expected/desired behavior
NumericTextBox shall not pop up the keyboard on mobile on scroll
Devices: all mobile
Bug Report
Pressing the dot key on the NumPad does not apply the default decimal separator when the keyboard is set to EN-US/ UK. It always applies the dot.
Steps for Reproduction
1. Set the culture to a culture that uses the comma as a decimal separator - Italian.
2. Switch the keyboard to EN-US/UK.
3. Press the dot on the NumPad.
4. Validation prevents the input.
Dojo sample for reproduction:
https://dojo.telerik.com/OXIsEVAk
Environment
jQuery version: 1.12.4
Kendo UI version: 2020.1.219
Browsers: [all]
Bug report
In case when culture is set to de-DE or nl-NL globally the NumericTextBox does not accept comma decimal separator from the Numeric keypad
Reproduction of the problem
Dojo: https://dojo.telerik.com/ARURAhOg
Current behavior
When comma from the Numeric keypad is pressed validation is fired.
Expected/desired behavior
Comma must be accepted as a decimal separator
Environment
**Kendo UI version: 2020.1.406
Incorrect number when decreasing the value via the keyboard in MS Edge.
Reproduction of the problem:
1. Open a NumericTextBox demo in the Edge browser.
2. Focus on input.
3. Increase the value to 3 using keyboard arrows.
4. Press the Tab button so NumericTextBox loses focus.
5. Press Shift+Tab buttons to bring the focus back to the NumericTextBox.
6. Decrease the value using the keyboard arrow.
7. Value is decreased by two, while it should be decreased by one.
Current behavior:
When decreasing by the keyboard arrow, the value of the NumericTextBox goes directly from 3 to 1.
Expected/desired behavior:
When decreasing by the keyboard arrow, the value of the NumericTextBox should be decreased by one without skipping values.
Environment:
* **Kendo UI version:** 2020.2.513
* **jQuery version:** 1.12.4
* **Browser:** Microsoft Edge 44.18362.1.0
There is a limit in kendoNumericTextBox to 14 decimals. The request is to manage 15 or more decimals.
When users see a field where they're expected to enter a dollar amount, a lot of people intuitively try to type something like "$45.30". However, since the shift key is forbidden, they get "445.30". I suggest allowing users to type in a single, superfluous dollar sign as the first character in a CurrencyTextBox, and then ignoring it during form submit.
I know it's not officially supported, but when you use it in hybrid mode in an iOS UIWebView, the events sometimes seems to get mixed up. Then when you clic on a filed, it jumps to the the next one while flashing the keyboard. It doesn't happen always, but just clicking in a few fields on a form and it starts. We had to rollback using it in our codebase. I have a video of the behavior and the code (based on your mobile sample).
When I enter the following entry in numeric text box "1k" should populate "1000" "1m" should populate "1000000" "1g" should populate "1000000000"
For cases where validation after the fact isn't good enough there should be an option that disallows setting numeric textboxes to null. If the user sets it to null and moves to another field the textbox should reset to 0.