ElseIf clause skipped completely

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

Else 'Use initiative to determine target

End If[/code]

Maybe use >=?

save those values you’re comparing to local variables so that you can actually see them in the debugger. If it were me :wink: I’d first assume that some of those comparisons aren’t 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.

Saw this exact same thing today.

Remember that if both HGLeftTarget > HGLeftLine.Ubound and HGRightTarget > HGRightLine.Ubound are true, only the first section will be executed.

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).

You have to place a breakpoint INSIDE each potential path if you want to see it step into the True code section.

Personally, I find elseif unclear in code.

For the sake of a few letters:

[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:

system.debuglog("HGLeftTarget=" + str(HGLeftTarget)) system.debuglog("HGLeftLine.Ubound=" + str(HGLeftLine.Ubound)) system.debuglog("HGRightTarget=" + str(HGRightTarget)) system.debuglog("HGRightLine.Ubound=" + str(HGRightLine.Ubound))

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.