Console Glitch

[SMcNeill]

So I was playing around with adding the missing console functionality into my personal repo, when I ran across this odd set of behavior:

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE
LOCATE 3, 5
PRINT 3,
PRINT 5
And the program is now stuck in an endless loop where it's doing nothing but scrolling the screen over and over to eternity...

The fix?

I dunno!  It seems like anything that changes can fix it!

Remove that LOCATE statement:

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE
PRINT 3,
PRINT 5It runs fine!

Remove the comma, leave the LOCATE in there:

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE
LOCATE 3, 5
PRINT 3
PRINT 5It runs fine!

It's some odd combination where LOCATE and PRINT value,  produces the glitch...

I'll dig into it, but promise nothing on this one!  It's an odd thing.  0_o!!

[Petr]

I see it as some column counter bug? I try this code for the same bug:

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE
BEEP
LOCATE , 5
PRINT CSRLIN, POS(0) 'add here :SLEEP for next bug...

(LOCATE contains maximal 5 parameters, bug occur only if second parameter is used)

[STxAxTIC]

I thought LOCATE was ever supposed to work in console like that. Any time I needed to fake what Steve is trying I would write my whole output to a buffer first just so it can print line-by-line

 FWIW, *should* the console be supposed to do this? Seems like a weird thing to be asking of it... but I just sweep up at the Library so I dunno...

[SMcNeill]

I see it as some column counter bug? I try this code for the same bug:

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE
BEEP
LOCATE , 5
PRINT CSRLIN, POS(0) 'add here :SLEEP for next bug...


The glitch is down in the libqb.cpp routine tab()  -- (it's the one which spaces things properly for us):

Code: C++: [Select]

1.     if (write_page->text){
2.         qbs_print(singlespace,0);
3.         text:
4.         if (write_page->cursor_x!=1){
5.             if (((write_page->cursor_x-1)%14)||(write_page->cursor_x>(write_page->width-13))){
6.                 if (write_page->cursor_x<write_page->width){qbs_print(singlespace,0); goto text;}
7.             }
8.         }//!=1
9.         return;
10.     }

That GOTO generates us an endless loop as the CONSOLE doesn't work properly with hardly any of the write_page parameters...

I've got it fixed in my repo now, but my fix is for WINDOWS ONLY.  Does Linux make use of the _CONSOLE command?  Does it have the same glitch?  Or Mac??

I dunno!

All I know is that I've had to go in and add CSRLIN and POS(0) support first for the console, before sorting sorting out the glitch in tab(), which makes me wonder, "Just how buggy is QB64 when it comes to working with our consoles??"


I'm going to see about sorting out LOCATE and a few other console commands for us, and then I'll end up pushing my progress into my repo later this evening so folks can test it out and see how/if it works for them.  If there's no real issues with people testing things, I'll push the changes into the official QB64 repo in a few weeks or so, and then they'll be part of our development build -- and eventually an official part of QB64's next standard build after that.  :!

[SMcNeill]

I thought LOCATE was ever supposed to work in console like that. Any time I needed to fake what Steve is trying I would write my whole output to a buffer first just so it can print line-by-line

 FWIW, *should* the console be supposed to do this? Seems like a weird thing to be asking of it... but I just sweep up at the Library so I dunno...

Check out the console library I was working on here: https://www.qb64.org/forum/index.php?topic=1540.msg107531#msg107531

Currently, CONSOLE *doesn't* work with LOCATE -- but it *should*.   I'll be patching that into the repo next, so expect to see the added functionality soon (if you've cloned Steve64 and are helping test changes to it as I go).

[SMcNeill]

Anyone know exactly how QB64 does comma spacing?

PRINT “A”, “B”

Is “B” always set at a constant position?  Does it change if fonts change?  Or screen dimensions?

Currently I’ve implemented my own simple position system into the console — every 10 spaces.  For example, if your console is 80 characters wide, you would have 7 stops at position 10, 20, 30...and so on to 70.  Beyond 70, you go to a new line and start over.

If we’re supposed to have some other spacing, and you guys know what it is, let me know and I’ll try and tweak it so the output would mimic what we’d normally see (at least for default fonts; I don’t know if I’ll worry with sorting out custom fonts ATM, as they could just be a real PITA to process).

[Petr]

Hi Steve. Shift is 15, as show my experiment. But - why are numbers writed to text screen from second column? Its because numbers are printed as strings and internally converted using STR$?

Code: [Select]

a = 5: b = 6
COLOR , 11
PRINT a, b
PRINT CSRLIN, POS(0)
PRINT "123456789ABCDEFGH"

This code show difference between printing numbers and text:

Code: [Select]

SCREEN _NEWIMAGE(800, 600, 32)
a = 5: b = 6
COLOR , 11
PRINT a, b
PRINT "a", "b"
PRINT CSRLIN, POS(0)
PRINT "123456789ABCDEFGH"


[SMcNeill]

Hi Steve. Shift is 15, as show my experiment. But - why are numbers writed to text screen from second column? Its because numbers are printed as strings and internally converted using STR$?

Code: [Select]

a = 5: b = 6
COLOR , 11
PRINT a, b
PRINT CSRLIN, POS(0)
PRINT "123456789ABCDEFGH"


Reserved space for the negative sign.

PRINT 1
PRINT -1

[Petr]

Oh yeah!

[SMcNeill]

14 characters, with default font:
$CHECKING:OFF
'$CONSOLE:ONLY
'_DEST _CONSOLE: _SOURCE _CONSOLE
LOCATE 1, 7
FOR i = 1 TO 30
    PRINT POS(0),
NEXT
PRINT "foo", "bbb", "vvv"

[Petr]

You are right, Steve.....

Code: [Select]

SCREEN 0
PRINT "a", "b"
DO
    WHILE _MOUSEINPUT: WEND
    LOCATE 1 + _MOUSEY, 1 + _MOUSEX
    Row = CSRLIN: Sl = POS(0)
    LOCATE 22, 1: PRINT Row - 1, Sl - 1
LOOP

:)

[Petr]

Another bug found. The text window jumps to _FONT8 when you cross the bottom edge of the window in my last untreated source code, an error message jumps that (if you continue to drag it into the window program) no longer returns the original font to the text window. I know you're doing something else, but when I'm testing it ...

  [ You are not allowed to view this attachment ]  


  [ You are not allowed to view this attachment ]  

And before error message:

  [ You are not allowed to view this attachment ]  

[FellippeHeitor]

Instead of a crash, Galleon made it so the screen would adapt when the user tries to print beyond the last line. It is by design. And not CONSOLE related.

[Petr]

Hi Fellippe. Aha, thanks for the information. It just surprised me.

[SMcNeill]

The tab glitch has been fixed.
Also have added support for the following commands for the console:
CSRLIN
POS(0)
LOCATE
COLOR

We can now find out where the print cursor is, locate it across the console to where we want it, and change the color of the text which we print to the screen.  There's still a few more things which I'd like to implement for us, so expect even more console goodness to be added in the next few days!  ;)