IDE oddity, not catching an error situation?

[Cobalt]

this code does not produce an error in my IDE! I would have though it would have thrown something but perhaps I'm wrong.

Code: [Select]

IF MO% = 19 THEN Oprint 18, 368, "Game", White, NORMAL ELSE Oprint 18, 368, "Game", Grey, NORMAL
 IF MO% = 20 THEN Oprint 86, 368, "Design", White, NORMAL else
 IF MO% = 21 THEN Oprint 164, 368, "Fleet", White, NORMAL else
 IF MO% = 22 THEN Oprint 236, 368, "Map", White, NORMAL else
 IF MO% = 23 THEN Oprint 292, 368, "Races", White, NORMAL else
 IF MO% = 24 THEN Oprint 366, 368, "Planets", White, NORMAL else
 IF MO% = 25 THEN Oprint 458, 368, "Tech", White, NORMAL else
 IF MO% = 26 THEN Oprint 524, 368, "Next Turn", White, NORMAL else

shouldn't it be complaining about nothing after the 'ELSE'? although its not capitalizing the 'else' until I add the condition.(if I use the code=64 the forum auto capitalizes it so had to remove the =64 to show it)
Is the proper behavior for QB64 not to care if there is a condition after an 'else' or is something else(no pun intended) going on?

[Petr]

I think that at ELSE no condition is checked (it is checked after THEN but never after ELSE)

[Bert22306]

Yes, I got the same result. The line of code isn't checked at all, it looks like. For instance, the "if" and the "then" are never forced to upper case (I always type such system words in lower case). Although the IF before the ELSE seems to work correctly.

[Pete]

OPRINT. WTH is OPRINT, a typo or a sub/function call? Well, if I strip out the "O" and just use print, it's fine. All we have is empty ELSE statements, which is fine, but just not good a good coding practice. I don't see this as an IDE bug, but maybe I'm not understanding the question, properly.

 IF MO% = 19 THEN print 18, 368, "Game", White, NORMAL ELSE print 18, 368, "Game", Grey, NORMAL
 IF MO% = 20 THEN print 86, 368, "Design", White, NORMAL else
 
The second line is just an empty ELSE statement. The same with all the others, which follow in the original code.

As a sub call, this works, too...

Code: QB64: [Select]

1. IF MO% = 19 THEN oprint 18, 368, "Game", White, NORMAL ELSE oprint 18, 368, "Game", Grey, NORMAL
2. IF MO% = 20 THEN Oprint 86, 368, "Design", White, NORMAL else
3. IF MO% = 21 THEN Oprint 164, 368, "Fleet", White, NORMAL else
4. IF MO% = 22 THEN Oprint 236, 368, "Map", White, NORMAL else
5. IF MO% = 23 THEN Oprint 292, 368, "Races", White, NORMAL else
6. IF MO% = 24 THEN Oprint 366, 368, "Planets", White, NORMAL else
7. IF MO% = 25 THEN Oprint 458, 368, "Tech", White, NORMAL else
8. IF MO% = 26 THEN Oprint 524, 368, "Next Turn", White, NORMAL else
9.  
10. SUB oprint (a, b, a$, c, d)
11. PRINT a, b, a$, c, d
12. END SUB

Pete

[Cobalt]

OPRINT. WTH is OPRINT, a typo or a sub/function call? Well, if I strip out the "O" and just use print, it's fine. All we have is empty ELSE statements, which is fine, but just not good a good coding practice. I don't see this as an IDE bug, but maybe I'm not understanding the question, properly.

yeah, Oprint is a custom print routine using a(slew of) bitmap fonts, its short for OrionPrint, as this is a clone of the game "Master Of Orion".
MO% stands for MouseOver, so if the player has the mouse over an area the text goes from grey to white. I was completing the routine when I just happened to look at the status area in the IDE and saw 'OK' even with unfinished IF\THEN\ELSE statements. and it wasn't auto capitalizing the 'else' on the unfinished lines either.

I've just never noticed it before and wanted to make sure that is proper behavior and that I hadn't stumbled upon something. Not sure why someone would want to leave code like that though. Maybe we should have 'poor coding' warnings! Of course I would get tired of seeing that message every time I'm writing code! :D

[Cobalt]

turns out the IDE doesn't mind somebody doing this either,

  if inkey$=chr$(27) then else

and again it also doesn't auto capitalize, which I think may be an actual bug if the syntax issue is not.

[Bert22306]

You beat me to it. I always use a much simpler case, to prove or disprove some bug. This has nothing to do with Oprint

Try this, shown exactly as it is when running the program.

Code: [Select]

x = 1
y = 2
IF x = 1 THEN PRINT "x=1" ELSE PRINT "x=0"
if y=2 then print "y=2"else
end

Notice how the last two lines are not upper case. It does work, but that second IF statement is begging to be highlighted in red.

[FellippeHeitor]

shouldn't it be complaining about nothing after the 'ELSE'?

The stray ELSE in a single-line IF statement is valid syntax and was also permitted in QB4.5 (just checked). Reprovable, but still valid.

Sounds like a threat, right? “Do this, or else...”

The capitalization not taking place is indeed a QB64 glitch. Don’t expect a fix soon, though, as it’s very low priority.

Good catch!

[SMcNeill]

Think of it as:

IF x = Whatever THEN
    blahblah = blee_blee
ELSE

END IF

Nothing invalid in the above, is it?  Then why would it be an error with:

IF x = Whatever THEN blahblah = blee_blee ELSE


There’s nothing wrong with the syntax; it’s just the capitalization checker that’s glitchy in this case.  ;)

[TempodiBasic]

Yeah
all this is logic... and we must admit that QB64 with the goal to emulate as much as possible QB45 takes all its bugs!
:-P

it is logic and correct following syntax also

Code: QB64: [Select]

1. IF a =1 THEN REM

but not  this

Code: QB64: [Select]

1. IF a =1 THEN 'REM

because REM is a keyword that do nothing
while ' is a metacommand or delimeter (like you want more call it).

Good Coding behind QB45 bugs... the future is Windows20 and not MSDos6.0