QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: SMcNeill on August 27, 2019, 08:09:30 pm
-
Pushed several of the changes that I'd been working on into the development repo for folks to start testing and enjoying.
So what's in there??
Mainly just stuff for windows users, as I don't have a Linux/Mac machine to test things and make certain that everything will play nicely or work for them. :(
So what's the Windows user's get??
_INFLATE$ and _DEFLATE$, so the can compress and decompress strings.
Window's CONSOLE support has been extended so that:
CSRLIN support added.
POS(0) support added.
LOCATE support added. (Works with optional parameters.)
COLOR support added.
SCREEN support added to get both character and color information of any point on the console.
tab() glitch fixed. (Which could cause an endless loop when printing with comma spaced text/numbers.)
_WIDTH support added.
_HEIGHT support added.
WIDTH support added, with 2 new parameters added so we can set the buffer width and buffer height also.
CLS support semi-added. (Doesn't accept colored backgrounds; it clears the screen black. I'm getting tired of working up console stuff which I probably won't ever use myself...)
SLEEP support added.
END support added so we now end with any keypress and not just enter.
_CURSORINPUT has been added, so we can get input from the console and tell what gives it to us.
_CINP(toggle) support added, which allows us to get single character keystrokes from the console.
_CONSOLEFONT FontName, FontSize support added, which allows us to change the font and font size we use for the console.
_CONSOLECURSOR _SHOW|_HIDE, cursorsize support added, which allows us to show or hide the cursor in the console, and to change its size (from 0 to 100), as desired.
Mouse events should now be detectable in the console. (With maybe as many as five mouse buttons being detectable.)
New keyboard commands added:
_CAPSLOCK -- returns 1 if caps lock is on, 0 if it isn't.
_NUMLOCK -- as above, but for num lock
_SCROLLOCK -- as above, but for scroll lock
_TOGGLE_CAPSLOCK -- toggles the caps lock state for us.
_TOGGLE_NUMLOCK -- same, but for num lock
_TOGGLE_SCROLLOCK -- same, but for scroll lock
-
A few quick notes on usage:
Most of the console commands will require that you either have _DEST _CONSOLE or _SOURCE _CONSOLE set, so QB64 will know whether or not to get/send information from/to the console, or your regular screen.
The new input method from the console might take a little getting used to from folks, as it behaves a lot like _DEVICES does for us.
First, you need to use the function _CONSOLEINPUT to get input from the console, and then you need to process it -- as illustrated below:
x = _CONSOLEINPUT
IF x = 1 THEN 'we're getting keyboard input
keyhit = _CINP 'get the code for the key hit
'do stuff and process it...
ELSEIF x = 2 THEN 'we're getting mouse input
PRINT _MOUSEX, _MOUSEY, _MOUSEBUTTON(1)
'do stuff with those mousebuttons as we want...
ELSE
'ignore any other input events, which might be a result of buffer flushing, resizing, or other junk we're not concerned with.
END IF
Otherwise, most everything should plug directly back into our existing commands, and should work behind the scenes for us. COLOR changes console color just as it'd change SCREEN 0 color (you just need _DEST _CONSOLE set first)...
A few caveats:
Last time me and Petr were testing and debugging, it seems as if international keyboards don't want to play nice with the _CINP command. There may be system settings one can tweak to avoid the issue; there may be some sort of command settings I've overlooked to fix the isssue, or it may just be something that doesn't play so nicely with international keyboards/language set-ups. It'll take some more time to test and look into the issue, but I am aware of it and still digging every chance I get. (The fact I don't personally have an international keyboard for testing makes sorting out any difficulty rather challenging...)
As for fonts, you can only use the fonts which your system supports for the console, and only with sizes that the console supports.... And I have no clue at the moment on how to get a list of those, other than right-clicking on a console window and looking at the properties tab... This too, I will try and dig further into, to try and decipher out how to make it a little more failure resistant.
-
A quick test program which folks can use, to see how things perform for them:
PRINT "Welcome to a demostration of the Windows Console System for QB64," PRINT "as overhauled by Steve!" PRINT "First, allow me to illustrate two newly implemented commands: SLEEP and CLS" Pause
PRINT "And now, I'll illustrate how to change colors in the console:" PRINT "COLORS:"; i;
"ON";
15 - i
Pause
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
PRINT "Here we're set at 120x50." Pause
PRINT "And here we no longer have a scroll buffer; it's also 120x50." PRINT "Notice the vertical scroll bar is gone?" Pause
PRINT "And here we now have both a vertical and a hortizontal scroll bar." PRINT "Be certain to scroll the bar so you can 'See' all the text." Pause
PRINT "And now, prepare as I do something amazing!" Pause
PRINT "TaDa!! Your font is now size 16!" Pause
PRINT "And just in case yours was already size 16, it's now size 24!" Pause
PRINT "And now, let's take a look at... MOUSE SUPPORT!!" PRINT "<<CLICK HERE TO CONTINUE>>" PRINT "WAAAAAAIIIIIIT A MOMENT!!" PRINT MID$("THE CONSOLE NOW HAS MOUSE SUPPORT?!!", i
, 1);
Pause
PRINT "And, of course, I can now work with LOCATE..." Pause
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." IF x
= 1 THEN 'don't update for mouse input
PRINT "Press <ANY KEY> to continue."
-
Hi Steve. Today I have successfully passed the exams necessary for my work, so I have time again if you want more tests. I think you can test the problem with your American keyboard. Just add another keyboard to your system - right-click on your speech in the windows at the bottom right of the menu next to the clock (you probably have an EN sign there) goto settings / general / add and install next keyboard to windows. Try Czech keyboard :). Then switch between keyboards with left shift + left Alt. I also use one physical keyboard for both languages. :)
-
Hi Steve. Today I have successfully passed the exams necessary for my work, so I have time again if you want more tests. I think you can test the problem with your American keyboard. Just add another keyboard to your system - right-click on your speech in the windows at the bottom right of the menu next to the clock (you probably have an EN sign there) goto settings / general / add and install next keyboard to windows. Try Czech keyboard :). Then switch between keyboards with left shift + left Alt. I also use one physical keyboard for both languages. :)
Installing the Czech keyboard, I seem to be able to detect all the keys with my keyboard -- though some of them do behave differently. Pressing the equal key, for instance, gives me a strange result of 13 0 -13 (key down, key up), or sometimes (0 13 -13) for the same sequence. It seems to always generate a 13 for down, -13 for up, with an additional 0 code inserted in with the down code; though sometimes before and after it..
For me, = when held down can be both (0 13) or (13 0), but when let up, I only get a result of (-13)..
A few different keys give oddly mapped results, but they give results. As far as I can tell, there's no dead zones anywhere on my keyboard. Exactly which keystrokes are failing to be reported on yours?
-
Hi. I don't understand one thing. Today, after running the IDE from your repo _CONSOLEINPUT, today reports invalid name. I didn't do anything about it. It worked the day before yesterday. Do you have any tip why and what it could be?
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
Hi. I don't understand one thing. Today, after running the IDE from your repo _CONSOLEINPUT, today reports invalid name. I didn't do anything about it. It worked the day before yesterday. Do you have any tip why and what it could be?
[ This attachment cannot be displayed inline in 'Print Page' view ]
A slight command name change from my repo to QB64’s. My version was using _GETCONSOLEINPUT, but I felt that GET could be removed and not affect readability/usability, so the command in the actual development build is just _CONSOLEINPUT.
Just add that GET before the name, and it’ll work with the version you downloaded and we’re testing yesterday. ;)
-
Oh yeah, Steve! You use in this example _CONSOLEINPUT, but in your repo version you use _GETCONSOLEINPUT!
-
Thank you, I just found out :) So, please how CPP version have using now for test? (internal/c/libqb.cpp) I try the first unrepaired (all three version have backup here) and if is keyboard switched to english, then is program compiled, so is none reaction for enter, space, all letters. Works Alt and Ctrl.
-
Try please switch to Czech and compiling, if then it is the same as here (because your default is English and me is Czech)
-
Thank you, I just found out :) So, please how CPP version have using now for test? (internal/c/libqb.cpp) I try the first unrepaired (all three version have backup here) and if is keyboard switched to english, then is program compiled, so is none reaction for enter, space, all letters. Works Alt and Ctrl.
Windows Key + SPACE changes the keyboard layout for me(from English to Czech and back), and both my repo and the current development build have no issues with the console reading input. Czech does give some strange results, but all the keys respond to input at least.
Is your current keyboard set as the windows default keyboard? Is Windows 10 up to date and current? I’m wondering what the difference is between your system and mine, which might be interfering with it working.
-
When the console is open, right click it and open properties. What's the current code page? Perhaps that is what's making a difference.
-
I don't have Windows 10, but Windows 7 SP 1. My updates are off. I did that at a time when Microsoft thought he could just download Windows 10 for me. Since this annoying update, I totally stopped Microsoft. Maybe she would also want to test it from other people. I'd hate to it is my mess, and I burdened you unnecessarily.
-
I do not have the option in the console properties to determine the current code page. So I ran CMD ---> CHCP and the result is 852.
-
It's not a burden; it's just an issue that's rather difficult for me to try and diagnose and fix, since I can't seem to reproduce it. The only thing I can think which might be affecting it, is if you have (or had) a secondary keyboard connected to your computer at one time, and it might be registered as the "default keyboard". The console reads from the standard input/output buffers, so as long as you can normally type into a normal console window, we should be able to get a result back from that buffer.
I'll keep digging into the issue to see what I can uncover.
-
I only have one USB keyboard. I would like to try it from someone else with Windows 7. Best from someone who doesn't use English as their default language. I don't know why, if is pressed Ctrl or Alt will fill the buffer you are reading from and then it works. Why isn't it direct? What exclusive character does Ctrl or Alt have? Isn't that again some C thing with his favorite CHR$ (0)?
-
Why do we need new functions _CONSOLEFONT etc.? It would be surely more sensible to simply use _FONT.
-
Why do we need new functions _CONSOLEFONT etc.? It would be surely more sensible to simply use _FONT.
I’m not entirely certain how you’d set the console font to work with _LOADFONT and _FONT. The Windows console will only let you use compatible fonts that are already installed on your system, so there’s no use for _LOADFONT. You’re not looking to load one from the file system into memory; just make use of the ones which windows already has available for you.
All we can really do with the console is specify which of the available fonts we want to use, the size, and the amount of boldness (which I didn’t implement).
What I’m curious about, is why we have both a _TITLE and _CONSOLETITLE command. Couldn’t that have been toggled with just a _DEST change?