Is this something the IDE should catch?

[Dav]

I kept getting a compilation fail for some reason.  Puzzled me for a while. Looked through the code, didn't see it at first, but I had unknowingly place a number between SUB's.  The IDE catches it when trying to put commands between SUB's, but not line numbers. It reports OK, but fails compile.  Probably the IDE should catch that, right?   Small example,...

SUB foo
END SUB
1
SUB foo2
END SUB

Edit:  same with labels too.

- Dav

[FellippeHeitor]

Very true.

[SMcNeill]

I don't think it's something the IDE should catch, but it shouldn't fail either.  Can't you do something like the following in QB45:

100 SUB foo
110 END SUB
120
130
140 SUB foo2
150 END SUB

labels and numbers between SUBS shouldn't do anything, except add a little whitespace into the code.  I don't see where they'd be an error to catch, but they also shouldn't be a glitch to stop compilation.  I think what you've found is more a bug than anything else.

[bplus]

Wow! I can see being hung by that! Who would think to look for such a thing?

Thanks @Dav I am putting this on my debug list.

Tons of times my app says press a key to quit and sometimes that key doesn't catch right off so I lean on it, THEN next thing you know I am printing a string of whatever into the code lines in the IDE where ever the curser happens to be.

[Dav]

Can't you do something like the following in QB45:

100 SUB foo
110 END SUB
120
130
140 SUB foo2
150 END SUB

Just to see, I tried typing that into QB4.5, and the ide separates SUB from main code so there's no problem with it.  It just puts 120 and 130 in the main code window.  Does the same loading a file like that.
 So, it does allow in between stuff, but puts it into main code window.

- Dav

[bplus]

I suppose the line numbers for Subs stay the same, that is nice soln by QB4.5 and BTW @Dav how do you have that working in Windows? (and @bplus do I want to get that?)

[Dav]

QB45 seems to work in Windows 7, but won't go fullscreen.  Windows complains about it on startup, but gives the option of 'ignore' and will let QB45 continue to run.

- Dav

[bplus]

Wait, QB45 is not QB4.5 is it?

[Dav]

Yes, I was talking about QuickBasic 4.5 compiler, the DOS 16-bit execuatable.  It runs for me in Windows 7.  here's a screenshot.

- Dav

  [ You are not allowed to view this attachment ]  

[bplus]

According to this I cant Run QB4.5 or equivalent in Windows directly:
https://programmingbasic.com/download-qbasic-for-windows-7-and-windows-10/

Not even sure what they are talking about is compiler version, doesn't look like it.

[Dav]

Hmm, that's interesting, and wrong.  QB45 runs for me here directly, without DOSBox or a VM .  I'm in Win7 32-bit.

Edit:  Oh...I think they are talking about Qbasic, which comes with a DOS install.

- Dav

[SMcNeill]

Just to see, I tried typing that into QB4.5, and the ide separates SUB from main code so there's no problem with it.  It just puts 120 and 130 in the main code window.  Does the same loading a file like that.
 So, it does allow in between stuff, but puts it into main code window.

- Dav

That’s the IDE at work, but if you write the program in another editor, and compile from command line, it works just fine without moving anything.  ;)

[FellippeHeitor]

Just to see, I tried typing that into QB4.5, and the ide separates SUB from main code so there's no problem with it.  It just puts 120 and 130 in the main code window.  Does the same loading a file like that.
 So, it does allow in between stuff, but puts it into main code window.

- Dav

The fact that the QB4.5 IDE does manipulate your source code to put lines where they belong is an indicative labels are not really supposed to be between subs (like everything else). The old qb4.5 compiler would ignore them, ok - but instead of altering one's code, it's fair the QB64 IDE should let you know it's not valid and prevent you from scratching your head later on.

Fail Early, Fail Loudly. http://oncodingstyle.blogspot.com/2008/10/fail-early-fail-loudly.html

Latest dev build contains a check for that now. Thanks, @Dav.