Unexpected behaviour of RUN statement

[zaadstra]

Hi,

I ran into a strange thing in my program, which after narrowing down to a piece of test code, might be a bug in the RUN statement.

In my program I am using the bottom line (locate 25,1) as status line.  This all works fine, and the printing on that line and elsewhere on screen doesn't cause screen scrolling.  In some part of the program, I can choose to restart and do this with the RUN statement, as this makes sure all files are closed and variables 'forgotten'.

After this re-RUN, the program screen starts scrolling when printing on line 23.  This isn't an issue at first run.

This small piece of code shows the issue.  First time you see a scrolling counter, and the two bottom lines are static as expected.  After re-RUN, line 24 is also used and the screen starts scrolling.  The status line (25) then also scrolls away.

I've been messing with CLS, changing to different SCREEN, making sure last print command isn't at bottom etc.
It looks like a re-RUN isn't a 100% clean restart of the program?
If you enable the GOTO Start line (jumps to line 1) the program doesn't break.  But then all garbage is not cleared ;-)

Any thoughts?

Code: QB64: [Select]

1. Start:
2. LOCATE 25, 1
3. PRINT "Nice status line! @"; TIME$;
4. LOCATE 1, 1
5.  
6. FOR i = 1 TO 400
7.    PRINT i
8.    FOR j = 1 TO 2500000: NEXT
9. NEXT
10.  
11. LOCATE 12, 12
12. INPUT "Press enter to RUN"; x$
13. CLS
14.  
15. 'GOTO Start
16. RUN
17.  

[Mad Axeman]

I'm just confused as to why it isn't doing it the first time it's run. There's nothing telling it to stop at line 23 and start scrolling????

[zaadstra]

After re- (re- re- ...) reading the wiki page for RUN,  I decided to use CLEAR and then jump to a StartOfProgram: label.

I assume that RUN does the same, only it seems to mess up the screen settings.

[zaadstra]

I'm just confused as to why it isn't doing it the first time it's run. There's nothing telling it to stop at line 23 and start scrolling????

I can only guess this is legacy behaviour,  as the ancient QuickBasic versions also had this feature.   I like it a lot, as you can have a scrolling screen together with a static line for status messages, as demonstrated in the code snippet.

You can use VIEW PRINT too to accomplish something like this, but this is far more easy to use.

[bplus]

I'm just confused as to why it isn't doing it the first time it's run. There's nothing telling it to stop at line 23 and start scrolling????

+1 I think so too! But why isn't it repeating on re RUN?

I don't how important this is but if you really need to "run" a program fresh, you could call it up under shell.

[Mad Axeman]

If you 'un rem' (that doesn't look right!) the GOTO Start and run it it'll keep working as on the first run. So what's different about calling 'RUN' from within a programme? Weird!

[bplus]

Well guess what?!

It runs fine in QB64 stable version 1.3, the RUN gets same results as the first pass.

So this is a difference between QB64 64 bit (Windows 10) stable 1.3 and stable 1.4.

[zaadstra]

If you 'un rem' (that doesn't look right!) the GOTO Start and run it it'll keep working as on the first run. So what's different about calling 'RUN' from within a programme? Weird!

The difference is that RUN also CLEARs all variables etc. and closes files. Then restarts program in memory.

Well guess what?!

It runs fine in QB64 stable version 1.3, the RUN gets same results as the first pass.

So this is a difference between QB64 64 bit (Windows 10) stable 1.3 and stable 1.4.

Now that is an interesting find!  I guess this is food for the QB64 techies now.

[Mad Axeman]

The difference is that RUN also CLEARs all variables etc. and closes files. Then restarts program in memory.

But when you first RUN the prog there's no variables/open files etc. so shouldn't be any difference.

[Pete]

RUN and CLEAR are messed up, period. They do not clear all values as they did in QBasic. If you know what is causing the problem, you need to set the value befor using the RUN statement. As an alternative, you could open another instance of your program with SHELL, and then end the first instance.

Pete

[SMcNeill]

RUN and CLEAR are messed up, period. They do not clear all values as they did in QBasic. If you know what is causing the problem, you need to set the value befor using the RUN statement. As an alternative, you could open another instance of your program with SHELL, and then end the first instance.

Pete

That would be the way I’d do it.

SHELL _DONTWAIT COMMAND$(0)
SYSTEM

[zaadstra]

RUN and CLEAR are messed up, period. They do not clear all values as they did in QBasic. If you know what is causing the problem, you need to set the value befor using the RUN statement. As an alternative, you could open another instance of your program with SHELL, and then end the first instance.

Pete

I do not have indications that variables are not cleared. That said, I usually preset most variables at start of program. 
It is only the screen layout that get messed up. 

As Bplus found out, this seems to be a bug introduced between versions 1.3 and 1.4.

[Pete]

It's been around a lot longer than v1.3. It's one of my pet peeves that has never gets fixed, especially the CLEAR statement.

Pete

[zaadstra]

Let's hope this can get some attention in the upcoming v1.5?   How hard can it be,  LOL !!!