Hi,
I'v taken a look at the progressbar - since I guesd it cood be used as a gauge control in an app I develeope.
By testing it at the samples I found your numeric updown there.
And since it did some "strange" things I went to the numeric up down sample.
At his moment I was hopeing you simply made a miste at the progressbar sample.
So my first exipriences I'm "keyboard oriented" - so i would never click 50 time on an up button to change a value of 20 to 70 :)
First thing - I can't focus the things via TAB - not that problem.
I focus it with the mouse - results very different.
Sometime it marks the whole numer - sometimes not.
Doubleclick does not (as expected) mark the whole field - it stops at the comma seperator.
Anyhow - I can mark it all - draging with the mouse.
Now I expect - everything marked - I type and this will replace the text :)
So I marked the "beta" value (1,14) and type 300.
I get??? YES 0 nothing else.
OK - some hack with focus and so goes on - I go in front of the 0 in the texfield and type 3 --- YES it is there.
Since the 0 is still in the field I see no 30 with the cursor between 3 and 0.
What is missing to get 300? A zero - so type it - the result?
0 - not this time NOT - I get 100 - the 0 goes in and the 3 changes to 1.
YES I found out why - the control is limited to 100.
OK - mark the 100 again (draging the mouse).
Type 99 - and get? 9 - type another 9 and get 99.
Mark all type 12 -- get 2....
OK - I take the value Shares.
I mark all type 321 and get 21 :)
I move the cursor to the front type 3 and get 321.
Ups I like 421 I move the cursor between 4 and 21 hit backspace than 4 and get?
Right - 214 - because hitting the backspace removes the 3 (as it should) and than moves the cursor back to the end of the number (not expected).
I'll stop now - I guess you can play for hours with that thing; alwas getting a funny result.
But you can't use such a thing in a production environment.
Starting from the fact that a marked number is NOT replaced by what you type and ending in setting the value to MAX if you type to much.
Expect you give 1.000.000 as max.
The user types (from a form) 3469738 and than (by mistake) another 0.
He gets? 1000000 -- all the number he did type are gone.
Do this in a normal control - you get Uuuuups a number to big - or it does not accept the last digit since the value is to large.
But forcing the user to retype complex numbers....
Was this control tested only by mouse?
Or did anyone put it on a from - navigate via TAB and enter numbers?
If so - why did nobody see that it "eats" the first number you enter?
Sorry for my anger - but a simple unit test on an input control should include a "replace by entering numbers".
And not doing such a simple test is not a sign of quality!
Regards
Manfred
I'v taken a look at the progressbar - since I guesd it cood be used as a gauge control in an app I develeope.
By testing it at the samples I found your numeric updown there.
And since it did some "strange" things I went to the numeric up down sample.
At his moment I was hopeing you simply made a miste at the progressbar sample.
So my first exipriences I'm "keyboard oriented" - so i would never click 50 time on an up button to change a value of 20 to 70 :)
First thing - I can't focus the things via TAB - not that problem.
I focus it with the mouse - results very different.
Sometime it marks the whole numer - sometimes not.
Doubleclick does not (as expected) mark the whole field - it stops at the comma seperator.
Anyhow - I can mark it all - draging with the mouse.
Now I expect - everything marked - I type and this will replace the text :)
So I marked the "beta" value (1,14) and type 300.
I get??? YES 0 nothing else.
OK - some hack with focus and so goes on - I go in front of the 0 in the texfield and type 3 --- YES it is there.
Since the 0 is still in the field I see no 30 with the cursor between 3 and 0.
What is missing to get 300? A zero - so type it - the result?
0 - not this time NOT - I get 100 - the 0 goes in and the 3 changes to 1.
YES I found out why - the control is limited to 100.
OK - mark the 100 again (draging the mouse).
Type 99 - and get? 9 - type another 9 and get 99.
Mark all type 12 -- get 2....
OK - I take the value Shares.
I mark all type 321 and get 21 :)
I move the cursor to the front type 3 and get 321.
Ups I like 421 I move the cursor between 4 and 21 hit backspace than 4 and get?
Right - 214 - because hitting the backspace removes the 3 (as it should) and than moves the cursor back to the end of the number (not expected).
I'll stop now - I guess you can play for hours with that thing; alwas getting a funny result.
But you can't use such a thing in a production environment.
Starting from the fact that a marked number is NOT replaced by what you type and ending in setting the value to MAX if you type to much.
Expect you give 1.000.000 as max.
The user types (from a form) 3469738 and than (by mistake) another 0.
He gets? 1000000 -- all the number he did type are gone.
Do this in a normal control - you get Uuuuups a number to big - or it does not accept the last digit since the value is to large.
But forcing the user to retype complex numbers....
Was this control tested only by mouse?
Or did anyone put it on a from - navigate via TAB and enter numbers?
If so - why did nobody see that it "eats" the first number you enter?
Sorry for my anger - but a simple unit test on an input control should include a "replace by entering numbers".
And not doing such a simple test is not a sign of quality!
Regards
Manfred
3 Answers, 1 is accepted
0
Hi Manfred,
Thank you for your comprehensive feedback about RadNumericUpDown. There is no need to apologize for the emotional text, I completely agree that the control has usability problems and I want to assure you that they will be our first priority for the upcoming service pack. If the problems in RadNumericUpDown are showstopper for you, just let me know and we will send you a preliminary build, once the fix is ready after several days.
I want to apologize for the caused inconvenience and I hope that this will not prevent you from using the rest of the controls.
Sincerely yours,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
Thank you for your comprehensive feedback about RadNumericUpDown. There is no need to apologize for the emotional text, I completely agree that the control has usability problems and I want to assure you that they will be our first priority for the upcoming service pack. If the problems in RadNumericUpDown are showstopper for you, just let me know and we will send you a preliminary build, once the fix is ready after several days.
I want to apologize for the caused inconvenience and I hope that this will not prevent you from using the rest of the controls.
Sincerely yours,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
0
TWT
Top achievements
Rank 1
Rank 1
answered on 26 Dec 2008, 04:44 PM
Any status on this issue? I have the latest trial and still see this as an issue with this control and the datepicker. Any work arounnd?
0
Hello Trent,
We have quite significantly improved the functionality of RadNumericUpDown since the latest post of Manfred. Would you give us a little bit more information about the problem you face by using NumericUpDown as well as the DatePicker control, so we can work on improving and revising for our next release.
Kind regards,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.
We have quite significantly improved the functionality of RadNumericUpDown since the latest post of Manfred. Would you give us a little bit more information about the problem you face by using NumericUpDown as well as the DatePicker control, so we can work on improving and revising for our next release.
Kind regards,
Hristo Borisov
the Telerik team
Check out Telerik Trainer, the state of the art learning tool for Telerik products.