On visual studio watch1
"NumbersLcl(xc, yc)" is 6,
"NumbersLcl(x1, y1)" is 7.
Both "y1" and "yc" are 0.
All variables are byte and NumbersLcl is (2,2) as byte. How can the following statement evaluate as true?

If y1 = yc And NumbersLcl(xc, yc) = NumbersLcl(x1, y1) Then isfound = False

Elaborate your question please.

Elaborate??? Okay. "If" statements evaluate a conditional statement and determine if the conditional statement is true or false to continue on. "If true and false then..." should ALWAYS come up with false and "If true or false then..." should ALWAYS come up with true in the conditional evaluation. I wasn't coming up with expected results so I turned trace on, stepped through the program and came up with a conditional statement that should have evaluated as false. IE "if 0=0 and 6=7 then..." was coming up as a true conditional. I asked why. When I looked at the variable values in the original statement. I wanted to know how I could turn a watch window on, verify the third and fourth variable values could be 6 and 7 and this still evaluates as a true statement.

As usual, I changed something in a different area and this statement starts behaving like it should have in the first place.
Immediately after the IF statement that was coming up true, I added immediately after it:
If y1 = yc Then
If NumbersLcl(xc, yc) = NumbersLcl(x1, y1) Then
isfound = False
End If
End If
(It said the first statement above was true and the second was false like it should have to begin with and the original line now evaluated as false as well.)
Both the original line and the new lines evaluated as false like it should have to begin with.
Again, can anyone explain this weird behaviour?

Upload a sample project demonstrating this behavior

That would be a little tough to do since my project isn't demonstating this behaviour now, I've found and corrected unrelated bugs in my code, and I probably couldn't create a small sample that would repeat the actions I saw.

I also don't know if adding the bugs back in and removing the one additional statement that cleared it up in the first place would cause the same behaviour now. (Even if I could remember the exact lines that I changed while fixing the bug.)

The entire program could in no way be considered a sample. It used to be repeatable, I established the conditional break, put the last two variables in a watch statement after I saw it evaluated to true. Saw they weren't the same value (6 & 7), went huh??? I stopped and reran the code, saw the variables remained 6 & 7 before the if statement, it still evaluated as true. Stopped the code, just added the one if statement shown in a previous thread. Both the old and the new if statements evaluated as false.

This all fits in the "IT CAN'T DO THAT!" statement that all of us at one time or another should have said at some times in our lives. I was hoping someone knew about how the debugging step function could produce an action it couldn't possibly do.
Just for grins I removed the added if statement again and it does repeat the same behaviour. So, the bug corrections don't fix the behaviour, adding a supposedly unrelated if statement does fix it. I'll see if I can produce a sample that is repeatable.

I have seen this behavior once before but it was due to a horrible design on my part, and i'm not saying your design is horrible ;)

Here is what happened:
I was using reflection in a C# application to generate a Select() query but it was a very expensive process so what I did was made a static (shared in VB) backing field to hold the select query so it was only generated once. It looked like this (this isn't the static example):

protected virtual string SelectQuery
    {
      get
      {
        if (!_selectQueryGenerated)
        {
          _selectQuery = GenerateSelectQuery();
          _selectQueryGenerated = true;
        }
        return _selectQuery;
      }
    }

The problem was that if I use the debugger and I hold the cursor over the property name, use a watch window to evaluate the property, or use the immediate window to evaluate the property -- it would set _selectQueryGenerated = true; but it would not set the _selectQuery to the generated query.

That being said you can sometimes have irratic behavior if you do too much in something the compiler thinks is "safe" to evaluate, and those bugs only happen if you're debugging something and evaluate a statement.

The problem still exists to this day in my code. I haven't gotten around to fixing it and since i'm aware of the problem its not a big deal .... as long as nobody else tries to debug my code :)

Looks like I found a VB.Net compiler error in VS. This repeats the behavior just before the Else statement. Make the last statement an If... End If removes the error.
Sub Main()
Dim xc As Byte
Dim x0 As Byte
Dim x1 As Byte
Dim yc As Byte
Dim y0 As Byte
Dim y1 As Byte
Dim nums(4) As Byte
Dim NumbersLcl(2, 2) As Byte
Dim offset2 As Byte
Dim numconf As Byte
Dim Solve_vertically As Boolean
Dim isfound As Boolean ' is this configuration valid
xc = 1
yc = 0
x0 = 0
y0 = 1
x1 = 0
y1 = 0
nums(0) = 4
nums(1) = 6
nums(4) = 7
numconf = 0
isfound = True 'start as valid - find out if not
NumbersLcl(xc, yc) = nums(4)
NumbersLcl(x0, y0) = nums(0)
NumbersLcl(x1, y1) = nums(1)
Solve_vertically = True
If Solve_vertically Then
If y0 = yc And NumbersLcl(xc, yc) = NumbersLcl(x0, y0) Then isfound = False
If y1 = yc And NumbersLcl(xc, yc) = NumbersLcl(x1, y1) Then isfound = False
Else
If x0 = xc And NumbersLcl(xc, yc) = NumbersLcl(x0, y0) Then isfound = False
If x1 = xc And NumbersLcl(xc, yc) = NumbersLcl(x1, y1) Then isfound = False
End If
End Sub

Arrays in .net framework are reference type. Don't compare references. Use Equals method.

If Solve_vertically Then
If y0 = yc And NumbersLcl(xc, yc).Equals(NumbersLcl(x0, y0)) Then isfound = False

If y1 = yc And NumbersLcl(xc, yc).Equals(NumbersLcl(x1, y1)) Then isfound = False
Else
If x0 = xc And NumbersLcl(xc, yc).Equals(NumbersLcl(x0, y0)) Then isfound = False
If x1 = xc And NumbersLcl(xc, yc).Equals(NumbersLcl(x1, y1)) Then isfound = False
End If

Edited 7 Years Ago by __avd: n/a

That's interesting, I finally put a watch on isfound. I step through the code, it highlights isfound = False, I execute the next step so it looks like it executed the command. isfound is still true and the rest of the code acts like it is still true.

I understand Arrays in .net framework are reference type, however individual items should be value types when worked on as an individual item assuming the base object type is still a value type. The following code both produce "7" on the output lines:
Console.WriteLine(NumbersLcl(xc, yc).ToString())
setvalue(NumbersLcl(xc, yc))
Console.WriteLine(NumbersLcl(xc, yc).ToString())
Console.Read()
End Sub
Sub setvalue(ByVal a As Byte)
a = 10
End Sub

kplcjl,

I apologies for posting misleading facts in my post #8. I didn't read source code properly. In your post, you are comparing byte values not an array . Your code is syntacitcally correct with some logical illness.

Code at post #10, where method SetValue has value - ByVal parameter. Try to use reference - ByRef parameter.

Sub setvalue(ByRef a As Byte)
        a = 10
End Sub

Hmmm, string is the odd duck value type because it acts like a reference type when you interface with C++. I bet that's true even if you compile your C++ in the .net framework. If you think about it, internally all data types are reference types. That's how you can change a local variable and the next time you look at it it has the same value. There are locations in memory where that data is stored and instead of copying the data to a new location the same memory location is used when passed as a ByRef object. (Again string is the odd duck. I bet BOTH variables get a new (same) reference location if passed byref and then changed)

Code at post #10, where method SetValue has value - ByVal parameter. Try to use reference - ByRef parameter.

Sub setvalue(ByRef a As Byte)
        a = 10
End Sub

NO, this was an example that an individual item in an array is a ByVal field. I WANTED to see two lines of 7 showing that I AM passing an actual VALUE, not a Reference, even if the value is contained in a reference. Try
Sub setvalue(ByVal a As Byte())
a(0) = 10
End Sub

If you think the original passed array has the same value in the first field, you are VERY wrong.

Interesting that I am logic impaired. I thought I was logical... readable, (at times) on the other hand...:)

This question has already been answered. Start a new discussion instead.