I have a RadNumericUpDown control that's *typically* used for integer input. However, on rare occasions, there is a need to enter a floating point value with up to 4 decimal digits - the bound property is actually a FLOAT.
I know I can configure the control with "NumberDecimalDigits=4" and it will work as expected. However, I dislike the trailing ".0000" that's displayed when the control is being used to enter INT values, which again, is most of the time.
So, is it possible to configure the control to *allow* decimal digits to be entered, but to not display them unless they exist? So, if I enter an INT, I want it to be displayed as an INT (no decimal digits), and if I enter a FLOAT I want it to be displayed as a float - with all entered decimal digits.
Thanks,
Jeff
I know I can configure the control with "NumberDecimalDigits=4" and it will work as expected. However, I dislike the trailing ".0000" that's displayed when the control is being used to enter INT values, which again, is most of the time.
So, is it possible to configure the control to *allow* decimal digits to be entered, but to not display them unless they exist? So, if I enter an INT, I want it to be displayed as an INT (no decimal digits), and if I enter a FLOAT I want it to be displayed as a float - with all entered decimal digits.
Thanks,
Jeff
9 Answers, 1 is accepted
0
Accepted
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 24 Feb 2014, 02:26 PM
Konstantina,
Thanks for the input - that's exactly what I needed. Once you gave me the property name, I wondered how I could have missed it in the docs. Looking at my local CHM doc file though, I see that it's not there. Looking online, I see the property is in the docs but was added in December of 2013 - so fairly recently. I guess its time to update my local doc file... ;^)
Thanks again.
Jeff
Thanks for the input - that's exactly what I needed. Once you gave me the property name, I wondered how I could have missed it in the docs. Looking at my local CHM doc file though, I see that it's not there. Looking online, I see the property is in the docs but was added in December of 2013 - so fairly recently. I guess its time to update my local doc file... ;^)
Thanks again.
Jeff
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 24 Feb 2014, 08:12 PM
I just noticed something odd after setting "HideTrailingZeros=True" and "NumberDecimalDigits=4". Here are some examples of input:
If I enter "1", the control displays "1" - as expected
If I enter "1.0", the control displays "1" - as expected
If I enter "1.1", the control displays "1.1000" - not as as expected
If I enter "1.51", the control displays "1.5100" - not as expected.
Basically, it seems that if I enter *any* (non-zero) decimal digits, the control prints the full, specified number of decimal digits. I'd expect the unnecessary trailing zeros to be purged.
Interestingly, if I enter "1.5", the control displays "1.5". So, that seems to be an oddly special case.
Thoughts?
Jeff
0
Hi Jeff,
Could you please share with us with which version of the controls you are experiencing the described behavior. I tried to reproduce it with the latest assemblies, but with no success. Attached I am sending you a short video of my attempt. Please feel free to correct me if I am doing something wrong.
Regards,
Konstantina
Telerik
Could you please share with us with which version of the controls you are experiencing the described behavior. I tried to reproduce it with the latest assemblies, but with no success. Attached I am sending you a short video of my attempt. Please feel free to correct me if I am doing something wrong.
Regards,
Konstantina
Telerik
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 26 Feb 2014, 02:01 PM
Konstantina,
I'm experiencing the reported issue using UI for WPF version 2013.3.1316.40. And, I don't see the mentioned attachment in your previous post.
Thanks,
Jeff
I'm experiencing the reported issue using UI for WPF version 2013.3.1316.40. And, I don't see the mentioned attachment in your previous post.
Thanks,
Jeff
0
Hi Jeff,
Please check again the attachment. Even with those assemblies you mentioned, I am still not able to reproduce the issue. Could you please send us a sample project, in which this can be observed. In that way we will be able to track down the source of the problem and resolve it in a timely manner.
Looking forward to your reply.
Regards,
Konstantina
Telerik
Please check again the attachment. Even with those assemblies you mentioned, I am still not able to reproduce the issue. Could you please send us a sample project, in which this can be observed. In that way we will be able to track down the source of the problem and resolve it in a timely manner.
Looking forward to your reply.
Regards,
Konstantina
Telerik
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 27 Feb 2014, 02:24 PM
Konstantina,
I found the culprit. The RadNumericUpDown acts as I described if:
- It's bound to a ViewModel property
- That property is a float data type
The control works correctly if I either 1) remove the binding all together or 2) change the data type of the bound property from float to double.
In my case, I need the binding, so I chose option #2. Though, I think it should work with a float property, so I assume it's a bug in the control.
Can you reproduce it using the above? If not, I'll try to work up a simple example.
Thanks,
Jeff
I found the culprit. The RadNumericUpDown acts as I described if:
- It's bound to a ViewModel property
- That property is a float data type
The control works correctly if I either 1) remove the binding all together or 2) change the data type of the bound property from float to double.
In my case, I need the binding, so I chose option #2. Though, I think it should work with a float property, so I assume it's a bug in the control.
Can you reproduce it using the above? If not, I'll try to work up a simple example.
Thanks,
Jeff
0
Accepted
Hello Jeff,
The issue is caused exactly by the float type - you see the NumericUpDown is meant to work with nullable double, and even if it is bound to other type it internally converts the value to double. This causes changes in the value itself: some lost digits, or in this case some added. And from here the logic for trailing the zeros fails. Please change the bound type to double and the feature should work as expected.
Regards,
Konstantina
Telerik
The issue is caused exactly by the float type - you see the NumericUpDown is meant to work with nullable double, and even if it is bound to other type it internally converts the value to double. This causes changes in the value itself: some lost digits, or in this case some added. And from here the logic for trailing the zeros fails. Please change the bound type to double and the feature should work as expected.
Regards,
Konstantina
Telerik
0
Jeff
Top achievements
Rank 1
Rank 1
answered on 04 Mar 2014, 02:09 PM
Konstantina,
As mentioned in my previous post, I have already changed the bound value from a float to a double and it's working as expected. However, I find it strange that the trailing zero logic is so broken with a float value. Anyway, I'm past this one now.
Jeff
As mentioned in my previous post, I have already changed the bound value from a float to a double and it's working as expected. However, I find it strange that the trailing zero logic is so broken with a float value. Anyway, I'm past this one now.
Jeff