Unexpected print output with TAB

[Petr]

Hi.
Please try this code. CHR$ is not printed 1x as expected, but first is printed CHR$(13) and then excepted CHR$. If in PRINT is not used TAB, this bug not occur. Used space in this code, TAB(2) is not enought space and _CONTROLCHR OFF disable some function in TAB, because if is _CONTROLCHR OFF deleted from code, is text printed as expected. (not to one row, but without CHR$(13)).

If is text insterted to string variable and then printed, is output correct.

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(800, 600, 256)
2. _CONTROLCHR OFF
3. FOR byte = 0 TO 255
4.     PRINT byte; TAB(2); CHR$(byte); TAB(14); 'unexpected printing CHR$ (more than 1 print with TAB)
5.     a$ = STR$(byte) + TAB(2) + CHR$(byte) + TAB(4) 'output as expected
6.     'PRINT a$;
7.     FOR rj = 7 TO 0 STEP -1
8.         IF byte AND 2 ^ rj THEN Binar$ = Binar$ + "1" ELSE Binar$ = Binar$ + "0"
9.     NEXT rj
10.     PRINT Binar$
11.     Binar$ = ""
12.     SLEEP
13. NEXT
14.  

OR is this correct output, if _CONTROLCHR OFF show me text formating characters? 13 is enter, so as symbol for next row, which is not printed, because text formating is disabled???

[SMcNeill]

I think there's a few things wrong here -- both in QB64 and with the code itself...

Code: [Select]

   PRINT byte; TAB(2); CHR$(byte); TAB(14); 'unexpected printing CHR$ (more than 1 print with TAB)

With the above, TAB tries to move us to an exact position on the current print line...   TAB(2) tries to move us over to the 2nd print position...  The problem here is that we've already PASSED that print position.   When we print byte, we print its value, as well as saving a spot for its sign, so we use 2 positions on the line to print to.... Our current print location would be back on the next line, directly below the byte, as illustrated with the code below:

Code: [Select]

SCREEN _NEWIMAGE(800, 600, 256)
'_CONTROLCHR OFF
FOR byte = 0 TO 9
    PRINT byte; TAB(2); CHR$(byte); TAB(14); 'unexpected printing CHR$ (more than 1 print with TAB)
    a$ = STR$(byte) + TAB(2) + CHR$(byte) + TAB(4) 'output as expected
    'PRINT a$;
    FOR rj = 7 TO 0 STEP -1
        IF byte AND 2 ^ rj THEN Binar$ = Binar$ + "1" ELSE Binar$ = Binar$ + "0"
    NEXT rj
    PRINT Binar$
    Binar$ = ""
    SLEEP
NEXT
Now, I don't think this would be the behaviour you're looking for with this particular set of code, so the code by itself is a little buggy...


With that said, however, it also seems as if QB64 is a little buggy in there somewhere.  With _CONSTROLCHR off, that TAB(2) isn't moving to the next line as it should, automatically.  Instead, it's printing the "new line" symbol on the screen as an ASCII character.  I'd definitely call it a bug in QB64, as I can't honestly think anybody would ever consider that to be the intended behavior of things. 

If you're at position 6 on a line, and then TAB(2), you should go to the 2nd print position of the next line for your print position -- NOT print a musical symbol onto the screen.

Odin should definitely move this into the bug section of the forums.  (At least, in my opinion, he should.)  If this isn't a bug, I'd love for someone to explain to me why it is the way it is.  I really can't fathom any reasonable explanation as to why someone would want it this way.