Tab() special behaviour in Console?

[zaadstra]

Hi,

I was programming a print line with the tab() function, and found it to print way too far on the line. While normally Tab() neatly prints next text on the same position in the line(s).
Isolation the code and doing some experimenting shows that Tab() works fine without console, but in the console it seems a constant bunch of spaces. Is this meant to be? I can't find notes on this.

Code: (Select All)

$CONSOLE:ONLY
_DEST _CONSOLE

zipfile$ = "TestingFile.zip"
datetab = LEN(zipfile$) + 4 ' v1.2
PRINT zipfile$; "<<"
PRINT LEN(zipfile$)
PRINT datetab
' ~~~~~
PRINT "hoi"; TAB(datetab); "test"
PRINT "hoihoihoihoi"; TAB(datetab); "test"

Output, run with and without the two console lines:



For now, I will add some code to resolve this manually.  But is this a bug, or a feature?

Thanks!

[Kernelpanic]

I find the whole thing a bit confusing, but of course you have to take the longer line of text into account when using a TAB key; otherwise I wouldn't know how it's supposed to work.

Code: (Select All)

$Console:Only

_Dest _Console



zipfile$ = "TestingFile.zip"

datetab = Len(zipfile$) + 4 ' v1.2

Print zipfile$; "<<"

Print Len(zipfile$)

Print datetab

' ~~~~~

Print Tab(datetab); "hoi"; Tab(7); "test"

Print Tab(datetab); "hoihoi"; Tab(4); "test"

[hsiangch_ong]

are you actually complaining tab() produces spaces?

you do not want it to produce a single character!  some programmers do not want a single "\t" character produced from it!

this is because usually this is interpreted as eight spaces.  in a single "character."  this is a lot for people.  who like to write deeply nested loops.  or python programmers.  i'm not sure if the python interpreter.  accepts tab characters.  for required indentation in function bodies and such.  but must have at least one space.  in front of each line.  which is the function body.

btw there's no need for _dest _console if you already have $console:only. unless you create a graphics screen. that is hidden but being worked on. you then need _dest _console. before you use print. otherwise the printing is not show.

[DSMan195276]

Hi,

I was programming a print line with the tab() function, and found it to print way too far on the line. While normally Tab() neatly prints next text on the same position in the line(s).
Isolation the code and doing some experimenting shows that Tab() works fine without console, but in the console it seems a constant bunch of spaces. Is this meant to be? I can't find notes on this.

It's just bugged, the TAB function does not have any logic to handle the console. I'm not sure if it uses the cursor position on the graphical SCREEN or just uses some default value, but regardless it doesn't attempt to determine where the console cursor position might be and thus doesn't produce the correct TAB length.

are you actually complaining tab() produces spaces?

No, he's complaining that it doesn't work as intended and produces the wrong number of spaces. You can see it in his screenshot, the console output isn't lined up like the screen output is.

[zaadstra]

Thanks all.  

I believe that Tab() jumps to the specified column on the current line, or the next if the current print position is right to the specified tab column. As written on the wiki. 

It may be a Console quirk,  I just also remembered that Print behaves shady when having calculations as argument. But here it hardly may be called a calculation ...

I replaced it with a Left$() and Space$() combi.  Many routes to Rome ...

[JRace]

Here's the result of some quick experimentation:


The results of your test, as compiled by QB64PE:

Code: (Select All)

TestingFile.zip<<
15
19
hoi                  test
hoihoihoihoi                  test

I aligned the last 2 lines of the above test, to clarify that the same number of spaces are printed on each line:

Code: (Select All)

         hoi                  test
hoihoihoihoi                  test

TAB(19) prints 18 spaces, so the next character printed will be on the 19th column AFTER the starting cursor position.

I copied/pasted the TAB()-generated spaces just to be sure:

Code: (Select All)

                  HELLO, WORLD, FROM COLUMN 19!

QB64PE's TAB() seems to use a column position that is relative to the current cursor column, rather than using an absolute column position based on the start of the display row. 


According to the QuickBasic 4.5 Help file:
The argument, column, is a numeric expression that is the column number of
the new print position. If the current print position is already beyond
column, the TAB function moves the print position to that column on the
next line. Column 1 is the leftmost position, and the rightmost position
is the current line width of the output device. If column is greater than
the output width, TAB wraps the output and the print position becomes
1+(column MOD width). If column is less than 1, TAB moves the print
position to column 1.


The GWBasic User Guide says the same thing as the QuickBasic Help file, essentially.


The QB64PE Wiki seems to say the same as the above:
Space characters are printed until the print cursor reaches the designated column%, overwriting existing characters.



QuickBasic 4.5, QBasic 1.1, and GWBasic 3.23 all yield the following results:

Code: (Select All)

TestingFile.zip<<
15
19
hoi               test
hoihoihoihoi      test

Looks to me like a compatibility failure in QB64PE.

[bplus]

Wouldn't a simple workaround for this be: Locate , column

Like this:
   

[SMcNeill]

Locate only works on Windows console.

[bplus]

Not really,

Screen 0 OK for sure!
   

[SMcNeill]

Screen 0 isn't a console/terminal.  It's a graphic screen emulating a classic text-only screen.

With any $CONSOLE or _DEST CONSOLE, Locate will only work in Windows.  Ir doesn't work on Linux Terminals.