TryParse

[ellpee]

Want TryParse to give me false if a text string won't parse to a decimal, in which case I'll do some throw/catch magic. Tried several variations including the following:

            if(decimal.TryParse(textBox1.Text, out result) == false)

Help?

 

[Skydiver]

That is correct. decimal.TryParse() will return false if the current contents of textBox1.Text cannot be parsed as decimal. That will make that if statement's condition true. E.g.

if(decimal.TryParse(textBox1.Text, out result) == false)
{
    // the text box value could not be parsed
}
else
{
    // the text box value could be parsed
}

 

[jmcilhinney]

The code you have is already doing what you say you want. Do you think it's not? If so, what exactly is the text in the TextBox that is being parsed that you don't think should be? Make sure you tell us what the actual value of textBox1.Text is when the code is executed and not what you think it should be. Set a breakpoint on that line of code and use the debugger to see the actual value at the time.

 

[cjard]

in which case I'll do some throw/catch magic

Don't use exceptions for flow control

Use a NumericUpDown to capture numbers from the user

 

[ellpee]

Well, I haven't been able to actually run it yet because of the error. The builder or debugger or whatever puts a squiggly line under result in the arguments, and tells me it can't convert from out bool to out decimal. Good news maybe, though, changing decimal.TryParse to bool.TryParse seems to have maybe fixed the problem. I'm getting comfortable with casting in general, but the TryParse syntax is a bit more confusing at my level of cluelessness. More news later if this still won't build.

 

[jmcilhinney]

The word you're looking for is "compiler" and it might have helped if you had explained that there was an error and provided the error message in the first place.

This is an example of why you should ALWAYS read the relevant documentation, or at least pay attention to Intellisense as you write your code. The point of a Try{Parse method is to try to get a value without throwing an exception. Where exactly do you expect that result to be? That's what that second parameter is for. If the method returns false then the string could not be parsed and if it returns true then the string could be parsed and the result is stored in that second parameter. That parameter is the same type as you're calling the method on. If you call decimal.TryParse then that second parameter is type decimal.

More of then not, you can actually just declare the variable in the method call and let the type be inferred, as you only need to use it inside the if block, e.g.

if (decimal.TryParse(inputString, out var outputDecimal))
{
    // Use outputDecimal here.
}

You should only declare it outside that block if you actually need to use it outside that block.

 

[ellpee]

Ah, the NumericUpDown thing seems like a way to eliminate user dumb stuff, albeit a wee bit tedious with larger numbers, e.g., 25 or 40. Eliminates the whole is it not numeric thing, but will still need to be sure a number (other than 0) was selected in each case. Thanks for pointing me to that one.

The word you're looking for is "compiler" and it might have helped if you had explained that there was an error and provided the error message in the first place.

This is an example of why you should ALWAYS read the relevant documentation, or at least pay attention to Intellisense as you write your code. The point of a Try{Parse method is to try to get a value without throwing an exception. Where exactly do you expect that result to be? That's what that second parameter is for. If the method returns false then the string could not be parsed and if it returns true then the string could be parsed and the result is stored in that second parameter. That parameter is the same type as you're calling the method on. If you call decimal.TryParse then that second parameter is type decimal.

More of then not, you can actually just declare the variable in the method call and let the type be inferred, as you only need to use it inside the if block, e.g.

if (decimal.TryParse(inputString, out var outputDecimal))
{
    // Use outputDecimal here.
}

You should only declare it outside that block if you actually need to use it outside that block.

Well, as luck would have it, another poster turned me on to the numericUpDown widget thatpretty much rules out any dumb non-numeric input by the user, albeit with the downside that apparently it also rules out decimal-point entries, only whole numbers. So no need for TryParse after all for this particular learning project, but thanks nonetheless for your explanation, including turning me on to var as a return option.

 

[jmcilhinney]

with the downside that apparently it also rules out decimal-point entries, only whole numbers.

Nope. Again, read the documentation. The actual case is that the NumericUpDown has a constant number of decimal places that you get to choose and that defaults to zero. If it was limited to whole numbers then the Value property would not be type decimal.

 

[jmcilhinney]

including turning me on to var as a return option.

It's not a "return option". var is how you declare a variable whose type is inferred. That's most commonly done by initialising said variable, e.g.

var str = "Hello World";

In that case, the type of str in inferred to be string because it is initialised with a string value. In this case, you can declare an out argument inline. Instead of this:

SomeType myVar;

SomeMethod(out myVar);

you can do this:

SomeMethod(out SomeType myVar);

or, if the parameter itself is type SomeType, use var and have the variable type inferred:

SomeMethod(out var myVar);

It's just a way to make code more succinct. Many believe that variables should be declared as close to where they are used as possible, so this is just an implementation of that.

 

[Skydiver]

As I recall, you can also type into the numeric up down control.

 

[jmcilhinney]

As I recall, you can also type into the numeric up down control.

Indeed, but it should be noted that, once you navigate away, the display will still contain the specified number of decimal places, whatever it was that you typed.

 

[ellpee]

Indeed, but it should be noted that, once you navigate away, the display will still contain the specified number of decimal places, whatever it was that you typed.

Yeah, about that. As counseled, I have indeed been doing my due diligence by checking the properties, googling, etc., but a question remains about the numericUpDown widget. If I set the decimal property to 2, it ALWAYS displays two decimal places, even for a whole number selection/entry. In my VBA experience there was a way, as I recall, to say "give me up to 2 decimal places, but only if necessary." Any built-in equivalent in C# forms universe, or would I need to write some code to handle that eventuality? This really a cosmetic issue, since 2 and 2.00 are the same thing for all practical purposes, just wondering.

 

[cjard]

You could override the paint and implement it yourself. This control doesn't allow you to specify a format like 0.##

I'd argue that it should show 2.00 as an indication to the user that decimals are acceptable and how many

the display will still contain the specified number of decimal places, whatever it was that you typed.

but also note that whatever you typed is the value, so if you type 1.2345 into a 2 DP NUD then it shows 1.23 but calling for .Value gives you 1.2345