Numeric Comparison gived a false result

[ShAAAMen]

Hello fellows!

I have a problem with this type of code:

Private sub button1_click()

Dim firstp as integer
Dim secondp as integer

Firstp = textbox1.text
Secondp = textbox2.text

If firstp >= secondp then
Msgbox("1 is equal or bigger")
Else
Msgbox("2 is bigger")
End if

This code sometimes works and sometimes gived me a false reault, like if textbox1 value is 50 and textbox2 value is 54
It still sais sometimes that the value of the first one is bigger

[aashish_9601]

I Suggest You use "Option Strict On" as the very first line in your code(class).

[Sitten Spynne]

You aren't making a numeric comparison. You're making a String comparison. That sorts Strings by the UTF-16 value of their character. (A lot of people call it the ASCII value but that hasn't ever been true in .NET.)

When you sort that way, "11" comes after "1" because "it is a longer String". But "121" comes before "2" because "it starts with 1, which comes before 2".

If you want to do a numeric comparison, you have to convert the TextBox Strings into some kind of numeric value like Integer. So:

Dim firstNumber As Integer = Integer.Parse(TextBox1.Text)
Dim secondNumber As Integer = Integer.Parse(TextBox1.Text)

Try that!

(That's why Option Strict was suggested. It warns you when you do things like this. It's off by default because that's how VB developers expected it to work 25 years ago and they pitched a fit when MS changed it.)

[Shaggy Hiker]

It looks to me like the problem may be a bit bigger than that. It all depends on whether that code was pasted in to the original post, or typed in. As it stands, there are two integer variables declared: firstp and secondp. However, the textboxes are put into Firstp and Secondp. Then the comparison is done with the first two. Those aren't the same variables, if this was pasted in, but in that case, since the comparison is between the two (unused) initial variables, they will both remain 0 and the comparison will always produce the same result, no matter what was entered.

So, just to get different results for differet values, the code in that first post has to have been hand entered, because Firstp and Secondp would case-correct to firstp and secondp. In that case, the strings in the textboxes would implicitly convert to integers, and the comparison would work fine.

Put those two points together, and I'd say that the code in the first post had to have been typed in rather than pasted in, and that it was typed incorrectly, because Sitten has the obvious answer.

[ShAAAMen]

first of all, thank you for the informative posts!

you have solved my problem and definatly helped me learn WHY!

[jmcilhinney]

With regards to Option Strict, rather than setting it On at the file level, which would require you to do it in every code file, I would suggest setting it On at the project level. You do that in the project properties. If you haven't already, I strongly suggest that you open the project properties and get a bit familiar with everything that's there. I often see questions asked that indicate that someone has made no effort to look at those properties.

I would also suggest that you go into the IDE Options and have a good look through there too. You won't remember everything but you'll get a feel for it and then know where to look if you want to change something later. You can set Option Strict On in those Options too and then it will be On by default for all future projects. You can then simply turn it Off at the file level on the very rare occasions that you actually need to. For the record, I've never needed to, although there are some areas, e.g. Ofice Automation, where it is required.

Finally, if your question has been answered, please use the Thread Tools menu above your first post to mark the thread Resolved. That way, we can see it without having to open the thread and read all the posts.

[ShAAAMen]

when i turn on 'Option Strict' i get MANY errors that i am not sure i know how to handle.

also, the solution was 'Sitten Spynne's comment, but for some reason it worked for a while and now it is returning 0 instead of the real result.

this is the code:

  On Error Resume Next
        TextBox3.Text = WebBrowser1.Document.Body.InnerText

        Dim LINECNT As Integer
        Dim ResultMR As String
        Dim s As String
        Dim word As String

      TextBox11.Text = TextBox3.Lines(64).ToString  
            s = TextBox11.Text
            Dim words As String() = s.Split(New Char() {" "c})

            For Each word In words
            TextBox11.Text = TextBox11.Text & vbNewLine & word

        Next
            LINECNT = TextBox11.Lines.Count
            ResultMR = TextBox11.Lines(LINECNT - 3).ToString




        Dim FirstPhraseA As Integer = Integer.Parse(Form1.TextBox11.Text)

        Dim SecondPhraseA As Integer = Integer.Parse(ResultMR)
        
        if FirstPhraseA > SecondPhraseA then
''etc
        end if

FirstPhraseA is getting the value just fine, but SecondPhraseA is returning 0, no matter what i do, and it used to work that way before!, also if i am looking at ResultMR i DO SEE the value i need, but it just fails when i try to parse it

[jmcilhinney]

when i turn on 'Option Strict' i get MANY errors that i am not sure i know how to handle.

That's generally what you'd expect because people generally write poor code that having Option Strict Off allows them to do. In pretty much every case, the issues are caused by the fact that you're making the compiler assume that you want to use a particular type when you are actually using some other type. The solution is almost always to explicitly convert or cast to the type you want to use instead of the type you have. For example:

Dim n As Integer = 100
 
TextBox1.Text = n

In that case, an Integer value is being assigned to a String property, which requires an implicit conversion from Integer to String. With Option Strict On, you need to make the conversion explicitly:

Dim n As Integer = 100
 
TextBox1.Text = n.ToString()

As you can see, it's simple. You want a String and you (should) know that you want a String so tell the compiler that you want a String instead of making it assume so.

As another example, let's say that you have bound a DataTable to a ComboBox. In that case, each item will be a DataRowView, which means that the SelectedItem will be a DataRowView. The SelectedItem property is type Object though. With Option Strict Off, you might do this:

Dim name As String = ComboBox1.SelectedItem("Name")

That gets the Name field value from the selected DataRowView but it's going to fail on two counts with Option Strict On. Firstly, that code is indexing the row by column name but the Object type has no appropriate property to be indexed. If you want to treat the object you get from the SelectedItem as a DataRowView then you have to tell the compiler that that's what it is, i.e. you have to cast it as that type. Furthermore, the Item property of a DataRowView is type Object too so if you are getting a String back then you have to cast as type String in order to assign it to a String variable:

Dim row As DataRowView = DirectCast(ComboBox1.SelectedItem, DataRowView)
Dim name As String = CStr(row("Name"))

So, all you have to do is go through your code and make sure that every value you are using is the type that it is supposed to be. Wherever an error is flagged, it almost certainly isn't, so cast or convert as required. If there are any that you simply can't work out, post the specific code and error message here and we can help.

[Shaggy Hiker]

I agree. When I started in .NET, I was writing with Option Strict OFF, since that's the default. When I turned it on for a moderately sized project I got more errors than VS could show. Virtually all of these were simple to fix. I was doing a bunch of implicit conversions from strings to numbers, so CInt() and CDbl() fixed perhaps 98% of the errors. Most of these were kind of meaningless anyways. These weren't user input, and there was no chance that the conversion would ever fail. However, while making those changes, I found one really interesting bug. It hadn't bitten me, yet, and I don't remember what it was, now, but the implicit conversion was working, it was just doing something that was totally wrong.

So, while you see a bunch of errors, they are mostly the same as mine were: Just a bit of sloppiness. Clean it up and you might find some surprise along the way. I'll also note that the program that I was talking about was essentially an equation that took three days to run. When I fixed all the implicit conversions and made them into explicit conversions, the equation took two days. So, the implicit conversions slowed my code down by 50%. It's unlikely that you will see such a dramatic difference, though, because the vast majority of programs spend almost all of their time waiting for the user to do something, rather than taking days to perform a calculation. Basically, in most programs, the speed up isn't noticeable. It IS still there, though.

[jmcilhinney]

Here's a perfect example of where having Option Strict Off and relying on implicit conversions can be an issue:

Option Strict Off
 
Module Module1
 
    Sub Main()
        Dim str As String = "1"
        Dim int As Integer = 1
 
        Console.WriteLine(str + int)
    End Sub
 
End Module

That code is adding a String and an Integer. What does that even mean? The fact is that it's meaningless. In order to give it meaning, one of the values has to be converted to the same type as the other and then the two values of the same type combined. There are two choices there and they will produce different results. One possibility is that the String could be converted to an Integer and then the two numbers added together. That would produce a result of the Integer value 2. The other possibility is that the Integer could be converted to a String and then the two text values concatenated. That would produce the String value "11". Obviously very different results. Which of those did the developer intend? Which will the application produce? The fact that those two questions need to be asked is exactly why having Option Strict Off is a bad idea. With Option Strict On, that code would fail to compile. The developer would have to specify which conversion they wanted explicitly and the compiler would do exactly that, so there's no possibility of confusion. That doesn't mean that you can't still write bad code but it makes a particular type of bad code far less likely.