In a dynamically loaded dll I have this little snippet of code:
In this case, trts.Length is 1. That's all it should be, and by looking at the value in trts it is 1, and the value of trts.Length = 1, and trts.Length > 1 is False. However, if I put a breakpoint on the If statement, code execution goes to the mErrors.AddString....or maybe it doesn't.
If the mErrors.AddString were actually executed, then a string would be added to mErrors, which would raise an event that is caught elsewhere. That event is clearly not caught, so it appears not to be raised, which suggests that the mErrors.AddString never happens.
Also, the line immediately after the If block is not reached, nor does it appear to be reachable, because if I attempt to put a breakpoint on the line immediately after the If block, VS pauses for a second then reports that it was unable to bind a breakpoint at that point.
Interestingly, while the debugger steps into the If block (even though it should not), then the next step is out of the method entirely and back to the caller, the code after the If block is being called. That code builds a string that ends up in a tooltip, and since the tooltip is (mostly) right, the code must be getting called.
So, debugging is going the wrong way at a condition, then skipping over the rest of the method, but execution is NOT going the wrong way at the condition and is NOT skipping over the rest of the method. The debugger is just doing the wrong thing.
This was an issue with VB6, but I have never before seen it in VS. I have a few more tests to perform to study the situation in greater detail, so I suppose this is more or less just a rant, but if anybody has anything to say on the topic, or tests I could try, I'd like to hear about them.
Code:
If trts.Length > 1 Then
mErrors.AddString("Something here")
End IfIf the mErrors.AddString were actually executed, then a string would be added to mErrors, which would raise an event that is caught elsewhere. That event is clearly not caught, so it appears not to be raised, which suggests that the mErrors.AddString never happens.
Also, the line immediately after the If block is not reached, nor does it appear to be reachable, because if I attempt to put a breakpoint on the line immediately after the If block, VS pauses for a second then reports that it was unable to bind a breakpoint at that point.
Interestingly, while the debugger steps into the If block (even though it should not), then the next step is out of the method entirely and back to the caller, the code after the If block is being called. That code builds a string that ends up in a tooltip, and since the tooltip is (mostly) right, the code must be getting called.
So, debugging is going the wrong way at a condition, then skipping over the rest of the method, but execution is NOT going the wrong way at the condition and is NOT skipping over the rest of the method. The debugger is just doing the wrong thing.
This was an issue with VB6, but I have never before seen it in VS. I have a few more tests to perform to study the situation in greater detail, so I suppose this is more or less just a rant, but if anybody has anything to say on the topic, or tests I could try, I'd like to hear about them.