Unknown bug connected to LOCATE

I cannot explain it. I've been noticing and exploring this bug for a year now, and I have not made any sense of it. It is a minute bug, and rather variable, perhaps a malfunction in the way SB code is compiled? Here's my dilemma at the moment:

FOR(I)=(0)TO(28)
 IF(I>LEN(T$)-1)THEN
  FOR(II)=(I)TO(28)
   LOCATE(0),(II):?" "*40;
  NEXT(II)
  BREAK
 ENDIF
 REM Other code not worth mentioning
NEXT(I)

Basically, in this code, the loop needs to break to prevent subscript-out-of-range errors in the array T$, and it does break, preventing errors as expected, but it does not execute the code before the BREAK command. It completely ignores it. You can put STOP in the FOR loop and it will not stop, the loop and everything in it is completely ignored. It is all tied in with LOCATE somehow, I've had many strange bugs with this command. Another bug I've had was with the INC command; it would not execute, and I was forced to replace it with the X=X+1 format. Most my programs are text based, I've been working with it for years now. These small, few, minute, and random bugs are rather persistent. I have no idea how to even begin to test for these bugs.

If you can't trigger the bug in less than 3 lines of code, then it's probably a mistake in your program.

If you can't trigger the bug in less than 3 lines of code, then it's probably a mistake in your program.

I don't see how that's possible in this case. I can confirm that the IF statement is executed, and I can confirm the BREAK is executed, and I can confirm the FOR loop and the code within it is entirely disregarded.

I tested the example you gave, and it seemed to work fine

Yes, I don't doubt that at all.. That code snippet is an exact excerpt from my code. It is impossible for the FOR loop to be ignored like that, and I don't understand how a potential bug somewhere else in the code could trigger that.

I'm going to put effort into researching this since I'm the only one experiencing the bug, and I'll report back when I've discovered a pattern.

Can you just post all of the code that caused the problem?

While trying to isolate the bug, I've inadvertently solved it. The code is still the same, I've changed something elsewhere in the program (outside the initial FOR loop). I still haven't an ounce of understanding. The only way the FOR loop could have been ignored is if its initial condition for I was greater than its final condition (FOR I = A to B ; Where A > B ), which was entirely impossible. Maybe my copy of SmileBASIC is broken somewhere.

Why do you call this a bug? What would you expect to happen? What happens? BTW, the code could be written cleaner, something like:

MAXINDEX=28
FOR I=0 TO MIN(LEN(T$)-1, MAXINDEX)
 REM some code
NEXT I
FOR J=I TO MAXINDEX
 LOCATE 0,J:?" "*40;
NEXT J

But this does not help explain what you think is going wrong.

Why do you call this a bug? What would you expect to happen? What happens? BTW, the code could be written cleaner, something like:

MAXINDEX=28
FOR I=0 TO MIN(LEN(T$)-1, MAXINDEX)
 REM some code
NEXT I
FOR J=I TO MAXINDEX
 LOCATE 0,J:?" "*40;
NEXT J

But this does not help explain what you think is going wrong.

Well, no, the FOR loops need to be within each other, it needs to retain that sort of order-of-operations, but that's a neat idea that I haven't seen before, I'll take something from that for the future.

Why do you call this a bug? What would you expect to happen? What happens?

...

Well, no, the FOR loops need to be within each other, it needs to retain that sort of order-of-operations, but that's a neat idea that I haven't seen before, I'll take something from that for the future.

I would ask, why do you think the FOR loops need to be within each other (they do not), but that would distract from the more important questions are the ones I asked: Why do you call this a bug? What would you expect to happen? What happens?

Why do you call this a bug? What would you expect to happen? What happens?

...

Well, no, the FOR loops need to be within each other, it needs to retain that sort of order-of-operations, but that's a neat idea that I haven't seen before, I'll take something from that for the future.

I would ask, why do you think the FOR loops need to be within each other (they do not), but that would distract from the more important questions are the ones I asked: Why do you call this a bug? What would you expect to happen? What happens?

I call it a bug because following it are errors that seemingly cannot be solved. When I really think of it, I really don't know a lot about it. All the inexplicable errors I've seen could be non-related to one another, it's just that they have always been present when dealing with text and LOCATE. I didn't create this forum post to try and solve it. I more or less created to see if anyone else experienced anything similar. And for the FOR loop thing, it won't work for what I need it to. The variables I and II are depended upon in logic statements and conditions throughout the for loop. There's a lot in that REM comment between the condition and the loop.

See, a question is only useful if it contains what needs answering. When you ask the question wrong, no-one can help you get to the answer.

Yeah. It was a very complex problem, and I didn't quite understand what was going on when it was happening.