I have an UltraNumericEditor set to NumericType double, minimum bound 0, maximum bound 1 and MaskInput and FormatString of n.nn and 0.00 respectively.
I use the spin button to spin the hundred's place to 5. I then move to the one's place and spin that digit to 1. I end up with 1.05. This is above the maximum bound. Admittedly, it "sort of" keeps the focus on that control when I leave it. However, I'm not sure if the end-user will pick up on this. Also, I say "sort of" because you can jump to another UltraNumericEditor and start using the spin buttons. You can't edit directly.
What's the recommended way for handling min/max limits? Do you recommend error providers?
Ideally, I would not like the user to be able to enter a number greater than 1 to begin with. If there's no way to prevent some cases (such as pasting in 1.99), I'd at least like to have a more direct notification than just keeping the focus ("sort of") on the control.
Do you have some advice, articles, or example?
Thanks,
Andrew
bibsoconner said:I would not like the user to be able to enter a number greater than 1 to begin with
I'm not following why setting the MaxValue property to 1.0 is not sufficient for this.
bibsoconner said:I'd at least like to have a more direct notification than just keeping the focus
You could handle the ValidationError event and show a MessageBox. Incidentally, the fact that you can "jump to another UltraNumericEditor and start using the spin buttons" sounds like it might be a bug.
Brian,
Thank you for the rapid response; I do appreciate it. I have attached a very simple demo project showing the behavior. Perhaps I have some of the settings wrong? If you play with the first numeric spin button, you will be able to set the number to 1.05, by first spinning the hundreds place to 5, and then the 1's place to 1(the digit to the left of the decimal point. Feel free to correct my terminology :)).
You will then be able to go to the second numeric up/down (using the mouse for example), and use the spin buttons to alter that one. I don't believe you will be able to type directly in the second box.
Since you've had these controls for a long time and they seem to be working great in general (I'm new to them but impressed), I'm guessing that I simply don't have the properties set correctly.
I'll play with the ValidationError.
bibsoconner said:you will be able to set the number to 1.05, by first spinning the hundreds place to 5, and then the 1's place to 1
That is actually by-design behavior. The value in the fractional section is irrelevant when you are in the integral section, i.e, each section evaluates whether the spin button should be enabled separately. The reason for this is that attempting to enforce the min/max range with each change in value could make editing very tedious, since the end user usually only changes the value by one character at a time. The entire value is evaluated when the user leaves the control.
bibsoconner said:You will then be able to go to the second numeric up/down (using the mouse for example), and use the spin buttons to alter that one. I don't believe you will be able to type directly in the second box.
That is a bug, thanks for bringing it to our attention. It will be fixed in a future release of the control.
Hello, I also ran into this issue. Looking in the forum I noticed this problem has been discussed before in the forum, here and here.
I think the expected behavior is validating the whole number (integers and decimals) against the min and max values when using the spinning buttons or the up/down arrows.
Also, the whole number should be incremented/decremented at the same time. For example, when incrementing the decimal part in 0.99, the next value should be 1.00, then 1.01 and so on until the maximum is reached.
Is there a feature request for this kind of behavior?
Thanks.
After a conversation with the original author of this topic (bibsoconner), it looks like the features I talked about are there already, but only if the SpinIncrement is defined.
Is that documented somewhere?
Infragistics Team:
I find I now need to absolutely make sure that the user can't exit the control (either to go to another control or to exit the form) if the value is outside the valid range. Given that you said there is a bug present in the infragistics controls, can you offer the most acceptable workaround? Or perhaps you have a new version that has fixed the bug?
This is what you wrote (your response is underlined).
In order to receive a notification when a bug is fixed, you must log an incident with Developer Support so they have your contact information.
Work-Around:
You might want to attempt to correct the issue on a mouse-down event of the control or alternatively set the value for the spin increment (easy fix). The following code will set the editor value manually to the max amount, however it may appear that the buttons no longer work because the minor scale will still increment.
i.e. Max = 1 Min = 0
when control editor changes from 0.99 to 1.02 the code sets value to 1, so when button pressed for down, the control again increments the decimal point values to 1.99. This will then fail again and set the current value to 1 again.
You'll need to correct this yourself or set current value to zero.
If ((uneCompQty.Editor.IsValid = False) AndAlso (IsNumeric(uneCompQty.Editor.CurrentEditText.Trim))) Then
Dim value As Double = CDbl(uneCompQty.Editor.CurrentEditText.Trim)
'** check for upper boundary mark
If (value > CDbl(Me.uneCompQty.MaxValue)) Then
uneCompQty.Editor.Value = CDbl(Me.uneCompQty.MaxValue)
End If
If (value < CDbl(Me.uneCompQty.MinValue)) Then
uneCompQty.Editor.Value = CDbl(Me.uneCompQty.MinValue)