To specify the allowable range of values for the control, set the Minimum and Maximum properties. Set the Increment value to specify the value to be incremented or decremented to the Value property when the user clicks the up or down arrow buttons. You can increase the speed that the control moves through numbers when the user continuously presses the up or down arrow by setting the Accelerations property.
And from the description I see you'll lose control functionality if you didn't set them. I didn't try it my hand but I'll.
Well, it certainly doesn't like me to leave the maxiumn/minimum properties blank. What would be the best option, then, to allow someone to enter any integer. I guess I could always use a regular textbox and validate it myself
Yes and no. MyNumericUpDown.Value is always something of type decimal, so if you want an int you still have to do a cast or a conversion. Like : int myInt = (int)MyNumericUpDown.Value;
Be aware for overflow, the range of an int is smaller than the range of a decimal.
OK I understand that. In the program I am writing there is a feature that generates a list of random integers in the range of MIN to MAX, where MIN and MAX need to be inputted by the user. So I figured I'd present the user with two spinner boxes (so eloquently called NumericUpDowns in c#). The problem is that I have to set a maximum and minimum, it seems, which means that the user can't just enter any ol' number. I could use a masked text box but it looks like they require you to specify a set number of digits. So I'm wondering if there's any other solution that allows me to be lazy and not have to evaluate the input myself to make sure it's an integer number. I'm fine with casting the value of a NumericUpDown as long as I can get around the range restrictions.
I suppose I could just put in -2,147,483,648 to 2,147,483,647 as the range, but that's probably not the most elegant solution.
>> but that's probably not the most elegant solution.
Well, if it didn't check the value against a range at all, that would be the most elegant solution.
Thanks for posting that link, it was what I was thinking of doing next. However I think I will just stick with setting the spinner box range. I hadn't thought about the fact that somebody could actually enter something large (or small) enough to cause an error when I cast the value, and setting the range prevents that, at least.