I found a QB incompatibility issue or a bug inolving LOCATE and STRING$()

[Pete]

The code demonstrates how a programmer needs to use the second routine to fill a screen with STRING$() in both QBasic and QB64, but the surprise was the second PRINT statement in the demo will appear on row #1 in QBasic, as expected, but in QB64, it will appear on row #2!

Code: [Select]

PRINT "This will not fill the screen, as intended..."
SLEEP
CLS
x$ = STRING$(80 * 25, 219)
PRINT x$;
SLEEP
CLS
PRINT "But this will..." ' Why does this PRINT statement appear on row #2 in QB64, after a CLS statement?
SLEEP
CLS
x$ = STRING$(80 * (25 - 1), 219) ' Print all but last row.
PRINT x$;
LOCATE _HEIGHT, 1
PRINT STRING$(80, 219); ' Print last row, separately to fill in the entire screen.
SLEEP
TheBOB was good enough to run it for me in his QBasic program, and reported that in QB, both messages are printed, as expected, on row #1, but for some reason, using the STRING$() statement in QB64 causes the second PRINT statement to appear on row #2, even though the statement directly before it is CLS. I would call this some sort of a bug, or is it just an incompatibility?

Pete

[bplus]

You are triggering a scroll with first bit of code. It's not string that's doing it.

Definitely something odd, here is demo of scrolling after line 24 is filled

Code: QB64: [Select]

1. PRINT "This will not fill the screen, as intended..."
2. SLEEP
3. CLS
4. FOR r = 1 TO 25
5.     FOR c = 1 TO 80
6.         PRINT RIGHT$(STR$(r), 1);
7.         _LIMIT 200
8.     NEXT
9. NEXT
10. SLEEP
11. CLS
12. PRINT "But this will..." ' Why does this PRINT statement appear on row #2 in QB64, after a CLS statement?
13. SLEEP
14. CLS
15. FOR r = 1 TO 25
16.     FOR c = 1 TO 80
17.         LOCATE r, c: PRINT RIGHT$(STR$(r), 1);
18.         _LIMIT 200
19.     NEXT
20. NEXT
21. SLEEP
22.  
23.  
24.  

' Why does this PRINT statement appear on row #2 in QB64, after a CLS statement?

Yes indeed! why?

I tried 2 CLS, still starts printing on line 2? Locate 1, 1 will fix but why needed?

[Pete]

Exactly. I t can be fixed with a LOCATE statement, that should not be needed, as CLS is supposed to set the cursor the row one, column one.

And yes... the solid string of characters triggers the scroll function. The only way around that is to do as the second code sample. My hunch is the QBasic developers had no other choice, as they wanted to preserve the screen scrolling ability, so they allowed a LOCATE at the last row to not scroll the screen, to make filling the screen possible. In other words, a LOCATE statement to the last row solves that issue. It just takes the fun out of doing something like making the last two rows a different color, by using COLOR 7, 1: PRINT STRING$(160, 32);. Instead you have to print the lines, separately. Anyway, that's not the bug of course, but making this example routine seems to have uncovered, what I would consider to be, a bug.

Pete

[bplus]

One work around: Set a color for last two lines, CLS and then reset color and print a giant block for the other color setting for 23 rows.

I have to agree that is a bug with starting on line #2 after a CLS.

[Pete]

I've used the VIEW PRINT trick, in past skin setups...

Code: QB64: [Select]

1. COLOR 7, 1
2. VIEW PRINT 1 TO 2
3. CLS 2
4. VIEW PRINT 24 TO 25
5. CLS 2
6. COLOR 7, 0
7. VIEW PRINT
8. COLOR 14, 1
9. LOCATE 2, 1: PRINT STRING$(80, 196);
10. LOCATE 24, 1: PRINT STRING$(80, 196);
11. COLOR 11, 1
12. msg$ = "Screen Zero Hero Program Screen"
13. LOCATE 1, 80 \ 2 - LEN(msg$) \ 2
14. PRINT msg$;
15. VIEW PRINT 3 TO 23
16. SLEEP

Pete

[bplus]

Ah VIEW PRINT haven't seen that for awhile!

[Pete]

It looks like the entire development team is turning a blind eye to this one. I won't stand for that. I'm looting the QB64 online store as we speak. Demonstrators are amassing by the thousands at The QBasic Forum, and are prepared to march! SCREEN ZERO MATTERS!

Pete

[SMcNeill]

This isn't an issue with either LOCATE, or STRING.  It's a glitch with PRINT and how it formats strings to work when they're longer than a single line.

Code: QB64: [Select]

1. CLS
2. x$ = STRING$(80, 219)
3. FOR i = 1 TO 25: y$ = y$ + x$: NEXT
4. PRINT y$;
5. SLEEP
6. CLS
7. PRINT "But this will..." ' Why does this PRINT statement appear on row #2 in QB64, after a CLS statement?
8. SLEEP
9. CLS
10. y$ = ""
11. FOR i = 1 TO 24: y$ = y$ + x$: NEXT
12.  
13. PRINT y$; ' Print all but last row.
14. LOCATE 25, 1
15. PRINT x$; ' Print last row, separately to fill in the entire screen.
16. SLEEP

When dealing with a string longer than what will fit on the screen, QB64 has to try to properly format it to follow the rules of QB45.  If your string is too long to fit on the current line, it automatically moves down to the next line to print.  See the simple demo below:

Code: QB64: [Select]

1. LOCATE 1, 71: PRINT STRING$(10, "X");
2. LOCATE 2, 71: PRINT STRING$(11, "X");
3. LOCATE 3, 71: PRINT STRING$(81, "X");
4.  

Your string of 80*25 characters is definitely longer than a single line, so it's triggering some sort of reaction from the PRINT positioning routine...  But, PRINT is one of those complex as hell commands, and nobody really knows what the heck is going on with it, and nobody wants to try and touch it with a ten foot pole! 

If the glitch as in LOCATE, or in STRING$, somebody might look into it.  Since it's in the PRINT routine itself, I don't think it's something anyone's going to be digging into soon.  (Unless Luke or Fellippe do it just to prove me wrong.  ;D)

[Pete]

Bob... Are our signs ready yet? Good, let's march! Sure, you may scoff, but those snow shoes of TheBOB's make a big impression!

Well, I agree, QBasic PRINT is a handful. I had plenty of experience with these types of situations making WP apps. There was always a way around, and maybe the team would rather just post this as an incompatibility in the WIKI, and provide the CLS: LOCATE 1, 1 as the workaround.

But, PRINT is one of those complex as hell commands, and nobody really knows what the heck is going on with it, and nobody wants to try and touch it with a ten foot pole!

I love your honesty in your reply. For me personally, this makes no difference if it does or does not get fixed. I just thought I should point it out. It's a bit like WP in WordPad and Notepad. You can mess the expected results up in those apps, too. It's rare, but it happens. QB64 and glitches are also rare, and I've always been very impressed at that fact.

Thanks for the reply,

Pete

[bplus]

Forget PRINT this should do it:

 LOCATE 1, 1 or equivalent in the CLS code.

[Pete]

If it were only that simple...

This would show otherwise:

Code: QB64: [Select]

1. LOCATE , , 1, 7, 30
2. FOR i = 1 TO 20: PRINT i
3. NEXT
4. VIEW PRINT 10 TO 25
5. SLEEP
6. CLS
7. SLEEP

So if you put CLS: LOCATE 1, 1, it would error out, as the VIEW PRINT statement requires the first printable row be row 10, not 1.

Pete

[bplus]

If it were only that simple...

This would show otherwise:

Code: QB64: [Select]

1. LOCATE , , 1, 7, 30
2. FOR i = 1 TO 20: PRINT i
3. NEXT
4. VIEW PRINT 10 TO 25
5. SLEEP
6. CLS
7. SLEEP

So if you put CLS: LOCATE 1, 1, it would error out, as the VIEW PRINT statement requires the first printable row be row 10, not 1.

Pete

Well then use the "or equivalent" ;-)) 

Wait, you can't use LOCATE with VIEW PRINT? no wonder I don't use it.

Shouldn't LOCATE, reLOCATE for VIEW PRINT screen section?

Wait CLS CAN reLOCATE for clearing, so why not full screen?

[Pete]

It's like the old saying goes, "Life's a bitch and then you SYSTEM."

Actually, you can use LOCATE with VIEW PRINT, you just can't use it outside the parameters, unless you want to LOCATE at the very last row. FOR instance, this will not throw an error:

VIEW PRINT 1 to 10: LOCATE 25, 1

Otherwise, all LOCATE statements would have to be at and between rows 10 and 25.

Pete

[bplus]

I am wondering how hard can it be for CLS to LOCATE 1,1 in non VIEW PRINT since it can readjust for VIEW PRINT.