Empty Textbox = Program crashes?

[srina]

The program I have written keeps crashing if the textbox is not filled in..how do I Prevent this?

this is the code I have this far..
'to make sure that user enters week number less than 52

If (txtReportingPeriod.Text > 52) Then
MessageBox.Show("Please enter the week number for this payroll period. Number may not be over 52.", "Error-Incorrect week number submitted.")

End If

[MetalInquisitor]

You're comparing a string to an integer, which can't be done. You have to first convert the string to a an integer so it can be compared to an integer.

Try this:

If CInt(txtReportingPeriod.Text) > 52 Then
MessageBox.Show(message)
End If

However, the best way would be to use Integer.TryParse. If it can't be converted to an Integer you can alert the user with an error message:

Dim num As Integer
        If Integer.TryParse(txtReportingPeriod.Text, num) Then
 
            If num > 52 Then
                MessageBox.Show("Please enter the week number for this payroll period. Number may not be over 52.", "Error-Incorrect week number submitted.")
            Else
                MessageBox.Show("It's a valid number under 52")
            End If
 
        Else
            MessageBox.Show("Not a valid number.")
        End If

[Joacim Andersson]

Your program will crash when there isn't any numbers written in the textbox so it doesn't have to be empty. The TextBox contains a string not an integer so you need to convert it to an integer first, just as MetalInquisitor mentioned above. However using CInt() will also crash your application since you can only use CInt if you know for certain that the string you're trying to convert can be converted to an integer, and since this is user input you can never be certain of that. The user might have written "Hello World" in the textbox, or as you've seen, left it empty.

So the correct way of doing it is either to use Integer.TryParse (as shown above) or use some other control that is specially made for inputting numbers, such as the NumericUpDown control instead of using a TextBox.

[srina]

would this apply to visual basic 2010 as well?not too familiar with the parsed code

[MetalInquisitor]

Well, this is the VB.NET (which of course includes VB 2010) section of the VB forums, so I would say yes.

[Shaggy Hiker]

Turn Option Strict ON for the project. You'll end up with lots of errors because you've been using implicit conversions. There are a couple problems with implicit conversions, and you've found one of them. Option Strict will force you to replace your bad habits with good habits, which will result in faster code which doesn't have bugs like this one.

TryParse was originally only available for Double, but starting with 2005 there was a TryParse for lots of different data types. The purpose is to avoid the errors that arise when you try to convert a string into a type that it can't be converted to. As it turns out, people on here end up writing somewhere around one example of the use of TryParse per day, because it is very common for people to be relying on implicit conversions. Partly this is because lots of classes don't teach proper conversion techniques, and possibly they even ignore the fact that there are different datatypes such that people don't even know that a string is not an integer and can't be compared to one without the two being converted into the same type. However, another problem is that Microsoft tried to make the language a bit easier to work with by leaving Option Strict OFF (you will find the setting on the Compile tab of Project|Properties) by default. That may make some code quicker to write, but it just causes trouble in the not very long run.

[Joacim Andersson]

I would like to second everything Shaggy said above. You will become a much better programmer if you turn Option Strict On and take the time to correct all the errors that will pop up by doing so.

When you have Option Strict turned off what you really saying is this: Hello mr. VB compiler, could you be so kind not to complain about the errors in my code and instead make educated assumptions of what my intentions are during run-time. The compiler will then say: OK, have it your way but don't come back and complain to me when your application fails with a nasty exception when you run it.

The thing with comparing a string with an integer is that they aren't the same thing so a comparison is really impossible to do. So since you've told the compiler to ignore that fact it will allow it and instead it will try to convert one of the types during run-time. However what is it that you really want to convert? Should the integer be converted to a string and then do the comparison or should the string be converted to an integer before the comparison is performed? Well, who knows (except you)? In this particular case the latter will be performed, in other words VB will try to convert the text in the text box into an integer and then compare it with the other integer you provided (in this case 52). However when the text can't be converted to an integer (in this case because no text was provided) it will fail with a nasty run-time exception. However, one could always argue that VB should try to do the opposite and convert the integer number (52) into a string and then compare them (using the larger than comparison in your code). You would in that case find out that if the number 6 would have been inputted into the text box that "6" is indeed greater than "52" since we're now doing a string comparison. "A" comes before "B" so "B" is greater than "Any", in the same manner "6" is greater than "5" so it's also greater than "5173".

Stop letting VB make assumptions during run-time and make sure you've instead made it 100% clear what your intentions are and let the compiler tell you if it is clear or not so that you can correct it if it wasn't clear and then you don't get these run-time exceptions some of the times (it's always the "some of the times" scenarios that are hard to debug later on).