I’m finding that when the If evaluates to false, the ElseIf is never evaluated and execution skips directly to the Else. This happens in the debugger when I’m stepping through and in the iOS Simulator when running the app. Any thoughts on what gives?
[code]If HGLeftTarget > HGLeftLine.Ubound Then 'No more targets in left fleet
ElseIf HGRightTarget > HGRightLine.Ubound Then 'No more targets in right fleet
save those values youre comparing to local variables so that you can actually see them in the debugger. If it were me Id first assume that some of those comparisons arent filed with the values I think they are… Once you rule that out and can simplify it down to something to demonstrate the problem more simply open a bug report. I
I sometimes use this to print values in place of using the debugger since it does not stop the program flow.
System.Debuglog(SomeStringVariable)
And of course you can use multiple STR(xx) to put numeric things into a string. You could add a line or two of code before the start of the IF / ELSEIF / ELSE block and see all of the values.
It looks like it’s not evaluating the ElseIf but I bet it is. I believe it’s a bug in stepping through while debugging, as opposed to an issue with compilation.
The debugger does not “step” onto each condition. It hits the initial IF and then steps into whichever one evaluates to true. It has been this way forever (or at least since 2005).
[code]If HGLeftTarget > HGLeftLine.Ubound Then
'No more targets in left fleet
Else
If HGRightTarget > HGRightLine.Ubound Then
'No more targets in right fleet
Else
'Use initiative to determine target
End If
end if[/code]
or even this, if both tests for boundaries lead to ‘do nothing’
If (HGLeftTarget > HGLeftLine.Ubound) and (HGRightTarget > HGRightLine.Ubound) Then
'No more targets in either fleet
Else
'Use initiative to determine target
end if
I hope you have some code inside those If’s otherwise it’ll just jump from the first If to the next working line of code after the If, if you’re doing a quick test of the structure, put some break’s or system.debuglog’s inside the If’s to see where it actually lands.
As for why its not going in there if the above is met, try system.debuglog all the variables just before the If so you can see their actual content, you might have found a bug in the IDE where its not reporting the correct values during the break, however unlikely that is.
When looking through other peoples projects who’ve asked me for help, I’ve seen many different reasons for not following expected code structure. Make sure that you haven’t got a more locally defined variable of the same name that is being picked up and used. Do you have threads/doevents?
If you’re still stumped, put this in right above the If and post the results here and we’ll see what we can do:
It should also be noted that you could have used a Select Case statement here for clarity:
Select Case True
Case HGLeftTarget > HGLeftLine.Ubound
No more targets in left fleet
Case HGRightTarget > HGRightLine.Ubound
'No more targets in right fleet
Case Else
'Use initiative to determine target
End Select
This is usually what I prefer over a cascade of if-then-else statements.
OK, that’s surprising. In my testing, both the If and ElseIf evaluate to false, and a breakpoint on the ElseIf never happens so I assumed it’s not being evaluated at all. I just tried a case where the ElseIf evaluates to True, and the debugger steps straight into the ElseIf code. So I learned something new. Thanks for clarifying this.
Is there a case when you might want to put a breakpoint on an ElseIf or Else statement? If not, should the IDE be updated to not allow this in the first place?
There are LOTS of situations to do that. Unfortunately, this is limitation in xojo, on most languages you can add a break point in each ElseIf and step thought the conditions, but not in xojo.