Minor change to SLEEP command with CONSOLE for Windows.

[SMcNeill]

As discussed and highlighted here: https://www.qb64.org/forum/index.php?topic=1807.msg110545#msg110545

Change has been pushed into the development repo to correct this issue.  SLEEP should no longer read "key up" presses in the console in Windows, and should only properly respond to key down events. 

[hanness]

Thanks! Very much appreciated.

BTW, I can't tell you just how much I'm loving QB64. I'm having a great time creating utilities that are highly useful to me with it.

[SMcNeill]

Thanks! Very much appreciated.

BTW, I can't tell you just how much I'm loving QB64. I'm having a great time creating utilities that are highly useful to me with it.

It seems as if you use the console quite a bit, hanness.  Try the following code and tell me if everything seems to work as it should on your system.  Petr was reporting some issues with the font sizing, but I'm not certain how widespread the issue might be.  It could be a keyboard layout issue where he's running a non-standard keyboard setup, or some such setting, but I can't seem to reproduce the problem to debug it.  The more people who test the changes, the more I can sort out and debug any issues which arise from those edge-case scenarios that I failed to notice.

Code: [Select]

$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE

PRINT "Welcome to a demostration of the Windows Console System for QB64,"
PRINT "as overhauled by Steve!"
PRINT
PRINT "First, allow me to illustrate two newly implemented commands: SLEEP and CLS"
Pause
CLS
PRINT "And now, I'll illustrate how to change colors in the console:"
FOR i = 0 TO 15
    COLOR i, 15 - i
    PRINT "COLORS:"; i; "ON"; 15 - i
NEXT
PRINT
Pause
CLS
PRINT "And now, we're going to have fun with the console size."
PRINT "Our original screen should be set at 80x25 for default."
PRINT "Press <ANY KEY> when ready to change modes."
Pause
WIDTH 120, 50
PRINT
PRINT "Here we're set at 120x50."
Pause
WIDTH 120, 50, 120, 50
PRINT
PRINT "And here we no longer have a scroll buffer; it's also 120x50."
PRINT "Notice the vertical scroll bar is gone?"
Pause
WIDTH 120, 50, 300, 300
PRINT "And here we now have both a vertical and a hortizontal scroll bar."
FOR i = 1 TO 50
    PRINT "See? ";
    _LIMIT 10
NEXT
PRINT
PRINT "Be certain to scroll the bar so you can 'See' all the text."
PRINT
Pause
WIDTH , , 120, 50
CLS
PRINT "And now, prepare as I do something amazing!"
Pause
_CONSOLEFONT "", 16
PRINT "TaDa!!  Your font is now size 16!"
Pause
_CONSOLEFONT "", 24
PRINT "And just in case yours was already size 16, it's now size 24!"
Pause
_CONSOLEFONT "", 16
Pause
CLS
PRINT "And now, let's take a look at... MOUSE SUPPORT!!"
LOCATE 10, 10
PRINT "<<CLICK HERE TO CONTINUE>>"
DO
    x = _CONSOLEINPUT
    IF _MOUSEX >= 10 AND _MOUSEX <= 38 AND _MOUSEY = 10 AND _MOUSEBUTTON(1) THEN EXIT DO
LOOP
PRINT
PRINT
PRINT "WAAAAAAIIIIIIT A MOMENT!!"
PRINT
PRINT
FOR i = 1 TO 40
    PRINT MID$("THE CONSOLE NOW HAS MOUSE SUPPORT?!!", i, 1);
    _DELAY .1
NEXT
PRINT
PRINT
PRINT "WOOOOOOOO!!!!!"
PRINT
Pause
CLS
PRINT "And, of course, I can now work with LOCATE..."
LOCATE 10, 10: PRINT "LOCATE 10,10"
LOCATE 20: PRINT "LOCATE 20"
LOCATE , 20: PRINT "LOCATE ,20"
Pause
CLS
PRINT "And, of course, I can now get back single character returns..."
PRINT "Press any key, and I'll give you the scan code for it.  <ESC> quits the demo."
PRINT
PRINT
DO
    x = _CONSOLEINPUT
    c = _CINP
    PRINT c;
LOOP UNTIL c = 1


SUB Pause
    PRINT
    PRINT "Press <ANY KEY> to continue."
    SLEEP
END SUB

EDIT: Change to fix command names as my personal repo and QB64's development repo have the commands named just a little differently.  (I use _GETCONSOLEINPUT and the development repo uses just _CONSOLEINPUT to reduce typing...)

[hanness]

That code, including the font sizing, seems to work just fine. I tried it on 2 systems:

System one uses an Nvidia 1050Ti display adapter and is using a 32" monitor at 2560 x 1440.
System 2 is a laptop with Intel HD Graphics 620 and a 15" 4k display.

Fonts seem to size perfectly on both and everything else was working flawlessly as well.

[SMcNeill]

That code, including the font sizing, seems to work just fine. I tried it on 2 systems:

System one uses an Nvidia 1050Ti display adapter and is using a 32" monitor at 2560 x 1440.
System 2 is a laptop with Intel HD Graphics 620 and a 15" 4k display.

Fonts seem to size perfectly on both and everything else was working flawlessly as well.

And that's why I'm having issues tracking down the glitch that Petr reported.  :(

Whatever the problem is, it's apparently an odd one which seems to only affect certain system setups (like dual keyboard or languages, or some such).  It's rather difficult to debug code when you can't reproduce the glitch.

Many thanks for testing that for me.

[hanness]

Steve, my sister works with both English and Spanish so her computer is configured with a dual language configuration. I'll get the details from her, but I've compiled the program using the Aug 28, 2019 Dev version of QB64 and sent it to her to test.

I'll let you know both the test results and what her dual language config is like as soon as I get a response from her.

[hanness]

I've gotten the results back.

My sister has two systems:

On the first system she is using only English as the language, but she has dual keyboard layouts installed (US English, and Spanish). The sample program works equally well with either keyboard layout.

The second system is a Windows tablet (Surface 3) on which she has both English and Spanish keyboards configured but the primary language is Spanish. Once again, the sample program works fine in any configuration on that system.

NOTE: I've never worked with multiple languages so I'm not sure how, or if, Windows can be configured with 2 seperate languages that you can simply swap between. If that is possible, that is NOT what she is doing.

I'll look into that and if that can be done, I'll get a system setup to test.

[SMcNeill]

It may be a setting unique to Petr’s system, with a non-US default language set, or a non-default keyboard setup.  Whatever it is doesn’t seem to occur on most systems, which is a good thing, but it’s going to take several more people using the console before the problem is narrowed down and sorted out. 

As it is, I’m just happy that it’s working as intended on as many systems as it is.  There’s always something which requires debugging in code, especially in unusual user-case systems, so I’d consider the improvements a nice upgrade for now, but users should know altering fonts may not be possible on all systems.

Heck, it may even be a user permission issue, or an antivirus issue which is stopping the console font change...  Without more, reproducible error reports, I just don’t have a clue what to dig into to debug the problem.  All I can say at this point is, “It seems to work on my system, your systems, your sister’s systems, and not his.” 

Just keep in mind, changing console font settings from their default settings may not work on all machines.  If you’re coding in a local environment (like for your personal use at home or work), you can test the code and if it works, it works.  If you’re going to code a console program to sell for use on various user machines, then I wouldn’t just assume font changes will work on all systems. 

For personal use, I’d *always* change the font size so my poor old eyes wouldn’t be strained reading the screen.  If I was coding for a client, however, I’d probably leave it up to them to change their console font manually, since I know it’s not always reliable under all circumstances, and I don’t know what those exception conditions are.