LOCATE can be a pain in the ASCII.

[Pete]

A newcomer asked some questions about the LOCATE statement, recently. It made me recall some past issues I had , decades ago.Just for discussion sake, I thought I'd post this. View the comments in the code to see what's happening.

Code: QB64: [Select]

1. PRINT "This will not fill the screen, as intended..."
2. SLEEP
3. CLS
4. x$ = STRING$(_WIDTH * _HEIGHT, 219)
5. PRINT x$;
6. SLEEP
7. CLS
8. PRINT "But this will..." ' And why does this PRINT statement appear on row #2, after a CLS statement?
9. SLEEP
10. CLS
11. x$ = STRING$(_WIDTH * (_HEIGHT - 1), 219) ' Print all but last row.
12. PRINT x$;
13. LOCATE _HEIGHT, 1
14. PRINT STRING$(_WIDTH, 219); ' Print last row, separately.
15. SLEEP

I recall doing my first WP program that I made some special conditions when the cursor went past the width of the screen, and was hanging in limbo until the next statement determined its fate. I wish I saved the initial problem somewhere, but I didn't, so sorry for being rather vague here. I'm just pointing out that LOCATE can seem to act a bit fickle at time, in my opinion, but I'm sure if all the workings were taken into consideration, there would be reasons for it having to act in a certain way, so as to not mess up other uses, I suppose. Anyway, run the example and see what you think. For whatever reason, printing to the entire screen with a semi-colon scrolls it, but if you leave the last line blank, relocate the cursor to that last line, and then print a solid row with a semi-colon, you're good.

The other part that is unusual is the "But this will..." statement should print on row #1, not row #2. It follows a CLS statement, which should reset LOCATE to 1, 1, but that STRING$ print statement appears to be interfering with that expected result.

/ramble

Pete