QB64 Phoenix Edition
Is the POS command in need of a fix? - Printable Version

+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: Is the POS command in need of a fix? (/showthread.php?tid=2000)

Is the POS command in need of a fix? - PhilOfPerth - 09-15-2023

When I try to print several lines of text, all indented to the same tab point (tab14), the lines are separated by a blank line.
Wiki says "Column tab prints may not always move 9 spaces past the center of the screen. Some may move text to next row.", which seems a bit "iffy". 
Is there a firm rule that applies here, or must I resort to a new Locate command?  Huh

RE: Is the POS command in need of a fix? - SMcNeill - 09-15-2023

Can you share some code to showcase what you're speaking about?

RE: Is the POS command in need of a fix? - PhilOfPerth - 09-15-2023

(09-15-2023, 04:30 AM)SMcNeill Wrote: Can you share some code to showcase what you're speaking about?

I can ( but pardon the quality of the script):
Code: (Select All)
Screen _NewImage(1024, 820, 32)
SetFont: f& = _LoadFont("C:\WINDOWS\fonts\courbd.ttf", 24, "monospace") '                                                 31 rows, 73 columns text, allows chr$(95)
_Font f&
Dim tiles(100, 2)
' Player's turn sequence is: Pick up, Arrange, Lay Down, Discard

For a = 0 To 11
    For b = 1 To 8
        tiles(a * 8 + b, 1) = b
    Next
Next
For a = 97 To 100: tiles(a, 1) = -1: tiles(a, 2) = 4: Next '                                                                letters are set to A-H and ? for blanks
For a = 1 To 100
    If a < 33 Then tiles(a, 2) = 1 '                                                                                         first 8*4 red
    If a > 32 Then tiles(a, 2) = 2 '                                                                                         next 8*4 green
    If a > 64 Then tiles(a, 2) = 3 '                                                                                         next 8*4 magenta
    If a > 96 Then tiles(a, 2) = 4 '                                                                                         4 blanks white
Next
For a = 1 To 100
    Select Case tiles(a, 2)
        Case Is = 1
            red
        Case Is = 2
            green
        Case Is = 3
            magenta
        Case Is = 4
            white
    End Select
Next

Print Tab(14);
For a = 1 To 100
    Select Case tiles(a, 2)
        Case Is = 1
            red
        Case Is = 2
            green
        Case Is = 3
            magenta
        Case Is = 4
            white
    End Select
    Print Chr$(tiles(a, 1) + 64); " ";
    If a Mod 25 = 0 And Pos(0) > 50 Then Print Tab(14);
Next

Sub red:
    Color _RGB(255, 0, 0)
End Sub

Sub green
    Color _RGB(0, 255, 0)
End Sub

Sub blue
    Color _RGB(0, 0, 255)
End Sub

Sub yellow
    Color _RGB(255, 255, 0)
End Sub

Sub magenta
    Color _RGB(255, 55, 255)
End Sub

Sub white
    Color _RGB(255, 255, 255)
End Sub

Edit: I've found that Pos(0) is 65 after printing a row, and if I add If Pos(o) >64 then Print tab(14); The row is not skipped. 
I was able to achieve the effect I wanted with If a Mod 25 = 0 And Pos(0) > 64 Then v = CsrLin + 1: Locate v, 14
but this seems a bit clumsy.

RE: Is the POS command in need of a fix? - SMcNeill - 09-15-2023

From the wiki:

Quote:Explanation: TAB moves the PRINT down to the next row when the current column position is more than the TAB position.

So what you're seeing is text starting at position 14 + 50(where you printed 25 characters + spaces) = 64.  You want to TAB 14 more spaces to start printing at position 78.  Your screen only has 73 columns, so that shoots you down to the next line and at position 5.   TAB notices, "Hey!  That's not what you wanted!", so it moves down another line and then prints at the 14th position as specified.

Can this behavior be tweaked?

I dunno.  This may be one of those old QB45 quirks that was built the way it is, just to maintain compatibility with existing legacy code.  Someone would have to test a QB45 version and see how it performs, and if that extra line is intentional or not.  From the way INPUT and some of the other legacy commands handle wrapping and new lines, I'd say this is more a "legacy feature" than it is any sort of glitch.  

Easy fix here?

If a Mod 25 = 0 And Pos(0) > 50 Then PRINT: Print Tab(14);

^ Just add in that manual PRINT to the statement yourself so you're certain that TAB starts at the left of the line and not on the line below the one you're currently printing on. Wink

RE: Is the POS command in need of a fix? - PhilOfPerth - 09-15-2023

OK Thanks Steve, your explanation cleared up the mud for me. 
The Wiki explanation is a bit vague, and vagueness is not something I cope well with.
I did manage to get around it with the Locate line that I showed:
If a Mod 25 = 0 And Pos(0) > 64 Then v = CsrLin + 1: Locate v, 14
but it's messy, and a bit longer, so I'll do as you suggest. 
Thanks for the help.