Text Only | Text with Attachments

QB64.org Forum

Active Forums => Programs => Topic started by: SMcNeill on August 09, 2019, 05:09:32 am

Title: Steve64 Repo
Post by: SMcNeill on August 09, 2019, 05:09:32 am
So I finally decided to sit down and make my own repo for QB64 stuff.  Before anyone asks, "Are you trying to break off from the QB64 team and do your own stuff?", the answer is, "Nope!"

All I'm out to do is set me up a nice little repo to play around in and test things out to see if I can make them work properly.  Github Desktop recently did an update to their GUI, and I'm wanting to test it out and learn it better.  I've also been wanting to test out adding the capability to have SUB/FUNCTIONs go anywhere in our code and still compile without issues -- like so:

Code: [Select]
PRINT foo

FUNCTION foo
STATIC x
x = x + 1
foo = x
END FUNCTION

PRINT foo
QB45 used to allow us to write code that looked like that, (the above would print 1 and then print 2 to the screen), and it's something I've long wanted to get working for us so that library files could be merged and kept together and $INCLUDEd at the top of our code.

So, this seemed like a good time for me to just work on it all together...  A repo for experimental changes and testing purposes, which I can use to archive things which I want to keep, as well...

You'll find the repo here: https://github.com/SteveMcNeill/Steve64

Currently there's 22 archives in it (zip, 7z, rar) and over 50 *.BAS files all saved there.

Inside the /source folder, you'll see my latest attempt to work out the kinks with the SUB/FUNCTION anywhere placement, in the qb64SFA.bas file, for those of you who might want to play around with it and test it out.  It compiles most small programs which I test  it on, but it dies when trying to compile QB64.bas itself, and I don't know yet exactly what the glitch might be.  I'll keep playing around with it as time and effort allows...

Anywho...   Enjoy!  Feel free to take, steal, borrow, or modify anything you want from the repo.  It's all 100% available for the public to make use of. 
Title: Re: Steve64 Repo
Post by: SMcNeill on August 16, 2019, 01:26:02 pm
Current differences in my repo and standard QB64:

Zlib has been added into the source and is now one of our “parts”.  This gives us two new commands, which can be used to compress and uncompress strings.

Function _DEFLATE$ (Text$)
Function _INFLATE$ (Text$, {Uncompressed_Size})


Custom IDE enhancements:

A clock in bottom of the screen.
$AUTOSAVE:minutes — a new command to time stamp and AUTOSAVE our work.
$REPLACE — a new command to set quick typing codes for ease of coding.


Differences between the repo and QB64:

OPTION _EXPLICT won’t throw errors for variables declared via SHARED in a sub/function.

When OPTION _EXPLICIT does throw an error, it overwrites the clipboard with a default DIM statement so the user can paste it in the appropriate place.  (If desired, of course.)

_INSTRREV now terminates with a return of 0, rather than going into an endless loop.

_PUTIMAGE can now work with the same _DEST and _SOURCE.

Corrected IDE error message for "Unidentified open control block" when a SUB/FUNCTION is open without an END SUB/FUNCTION.


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.

_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.


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

Further details can be read in the posts which follow.
Title: Re: Steve64 Repo
Post by: RhoSigma on August 16, 2019, 01:40:44 pm
Quote
'Note:  _INFLATE$ requires that we know the size of the original text to get it back properly.
'           When saving your compressed data, it's probably a wise idea to save it with the legnth
'           before the compressed information, like most archives, images, ect does.

Why not doing this automatically within _DEFLATE? I do it the same way in my LZW packer lib, just after you copied the compressed string over into the qbs string simply add MKL$(originalSize) to it.
Now _INFLATE$ can just look at the last 4 bytes of the given compressed string, CVL() it and use it.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 16, 2019, 01:57:02 pm
Quote from: RhoSigma on August 16, 2019, 01:40:44 pm
Why not doing this automatically within _DEFLATE? I do it the same way in my LZW packer lib, just after you copied the compressed string over into the qbs string simply add MKL$(originalSize) to it.
Now _INFLATE$ can just look at the last 4 bytes of the given compressed string, CVL() it and use it.

I’d considered doing that, but if somebody uses the routine to open other files (like a PNG image), you’re not going to get those bytes tacked on to it.  We’d end up with corrupted/incomplete data.

I also considered making it an auto-sizing routine, but worry it could become very CPU expensive and time consuming...

DO
    BuffSize = BuffSize + 3000000
    ‘Try the extraction
LOOP UNTIL result <> -3 ‘zlib tosses a -3 result for buffer not large enough

Basically resize and keep trying until the buffer is large enough to hold the uncompressed data — but how much delay would that generate, with a 600MB compressed file?

Best solution might be to make that parameter optional.  If it’s there, go directly to uncompress that size data; otherwise resize until we get a valid result.
Title: Re: Steve64 Repo
Post by: RhoSigma on August 16, 2019, 02:31:13 pm
To reduce the amount of loops until the buffer is large enough, you could make a good guess on the initial size.

What's the average compression ratio zlib does reach (needs some testing with different filetypes of course), for simplicity lets assume 75%, then you could start with a buffer size which is at least 4 times as large as the passed in compressed data. In best case it's already large enough, in worst case you have to expand the buffer. Expanding coud than be done by adding another eg. 25% of the current buffer size bytes (that's IMHO better than adding a fixed size). All what you must do in the end is to return only the finally used size of the buffer, because the buffer becomes probably larger than finally required for unpacking, but i guess zlib inflate will return the unpacked size on success.

As this buffer enlarging probably takes place in your created C-function for _INFLATE$ you could simply use realloc() for this purpose, which would do the task as efficient as possible.

Hence:
bufSize = inSize*4;
mem = malloc(bufSize);
If required {
    bufSize += (bufSize \ 100 * 25);
    realloc(mem, bufSize);
}
Title: Re: Steve64 Repo
Post by: SMcNeill on August 18, 2019, 06:02:25 am
ZLIB has now been successfully integrated into QB64's parts system.

Now, I'm certain a lot of folks have no idea what that statement means, so I'll explain it, briefly:


Basically, QB64 calls on several various libraries to make their options available for us.  If we need those libraries, we include them in our EXE which we generate, else we leave them out.  Galleon called this QB64's "Part's System" where we can include and exclude only the parts which are needed for our code.  It was his attempt to try and decrease the size of EXE files created by QB64, and helped considerably (though it could help more, if QB64 made more use of it than it currently does).

The ZLIB library, which I've added to my repo, has now been integrated into that parts system.  If you use _DEFLATE$ or _INFLATE$, then QB64 will automatically link to those libraries and add the necessary functionality into the language for you.  If you don't need them, you go on creating EXE files the same as before, with ZLIB nowhere in your code.

As long as you're a Window's user, you should be able to grab a copy of my repo and run code such as the following, with no problems:

Code: QB64: [Select]
  1. text$ = "I like cheese."
  2. FOR i = 1 TO 10: text$ = text$ + text$: NEXT
  3. de$ = _DEFLATE$(text$)
  4. PRINT LEN(de$), LEN(text$)
  5. PRINT de$
  8. o$ = _INFLATE$(de$, LEN(text$)) 'Note:  _INFLATE$ requires that we know the size of the original text to get it back properly.
  9. '                                When saving your compressed data, it's probably a wise idea to save it with the legnth
  10. '                                before the compressed information, like most archives, images, ect does.
  11. '                                Just:
  12. '                                PUT #filehandle, ,OriginalSize
  13. '                                PUT #filehandle, ,CompressedString
  15. PRINT LEN(o$), LEN(text$)

Now all I need to do is sort out how the heck to colorize the keywords, so they'll be the proper color and not white in the IDE.
Title: Re: Steve64 Repo
Post by: RhoSigma on August 18, 2019, 07:35:25 am
Quote
Now all I need to do is sort out how the heck to colorize the keywords, so they'll be the proper color and not white in the IDE.

The keywords list is here qb64\source\ide\ide_global.bas around line 120. As far as i found out it's the only list, which holds regular as well as meta keywords. I guess the different coloring in the IDE is then done on the fly by checking if the keyword starts with a $ sign, then meta-keyword color is used, otherwise regular keyword color.
I've added _INFLATE/_DEFLATE as well as your $COLOR meta keyword and it seems to work properly.

BTW - Congrats and thank you for this valueable addition.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 18, 2019, 07:58:03 am
Change pushed into repo; we now have the keywords properly colorized inside the IDE. 

Many thanks, Rho, for pointing out the proper place for those.  I was searching all over the dang place and couldn't find them!  ;)
Title: Re: Steve64 Repo
Post by: SMcNeill on August 18, 2019, 08:11:16 am
Thought I'd also point out, for those who are cloning my repo and might not know, Steve64 repo also has a few other features which I use/abuse, which the standard QB64 doesn't have.

* There's a clock down at the lower part of the screen, as I always lose track of time when coding.  Without it, I'd never know what time of day it is, usually.

* There's also the inclusion of the $AUTOSAVE command, which will save timestamped copies of your work, for when you want that extra sense of security for large projects.  Sure, we have CTRL-Z for undoing things, but it's a real PITA to back up 10,000 times and try and undo back to where you were an hour ago.  $AUTOSAVE lets us specify a time and then QB64 will autosave our work every X amount of time (as long as our work has changed).  Usage is:

$AUTOSAVE:minutes

So, a working example would be the following to autosave our program every 15 minutes, with a fresh timestamp:

$AUTOSAVE:15

There's a few other little tweaks and changes to things in the repo, but nothing too major.  OPTION _EXPLICIT doesn't complain when we declare a variable via SHARED inside a sub.  When we get an error with option explicit, it gives us a DIM statement all set up in our clipboard, so all we have to do is paste it in the  proper place where we want it.  Maybe a few other things, but I can't think of what they are off the top of my head.

Just be aware; Steve64 isn't 100% QB64, as it's my own personal version of QB64 which I tend to tweak and alter shamelessly so that it'll behave the way that's most efficient for my programming needs/style.  ;)
Title: Re: Steve64 Repo
Post by: SMcNeill on August 19, 2019, 12:47:52 am
As talked about above, with RhoSigma (Is anyone else even looking at this topic?  All I hear is crickets from the user base here...  :P), the second parameter on _INFLATE$ has now became optional.

Personally, I wouldn't recommend using it as an optional parameter, but ultimately, that's now up to you guys.

The way it works is exactly as I described above -- set an initial size for the decompression buffer, try and decompress and see if we manage to decompress in the buffer allocated, and if not, try again.  And again... And again... And again...  ...Until we have enough of a buffer to finally hold the uncompressed data.

What could be one pass of the decompression routine (with you passing it the correct size in advance), may instead end up being dozens (or potentially hundreds) of passes as we keep trying and allocating more and more memory until we know how much we need.  It's not efficient.  It's not something I personally think folks should do very often (if at all).  BUT, I'll be the first to admit -- I'll probably be using the option myself.  (The initial buffer is set at 10mb in size, so I imagine that it'll be large enough to hold most things I'd need decompressed -- a 1600x1200x32-bit image is less than 8mb, for instance -- so it'd just be a shortcut for usage with relatively smallish files for me.)

Initial buffer size is 10mb, and it resizes by 10mb per attempt, so a 500mb compressed file would take 50 tries before it automatically resized to allocate enough memory to decompress it.  (For heaven's sake though, if you're working with compressing 500mb files, use an extra 4 dang bytes to store the size at the front or the end of the file, and save the world the hassle!)

A very quick example of the changes in action would be a program like this one:

Code: QB64: [Select]
  1. text$ = "I like cheese."
  2. FOR i = 1 TO 20: text$ = text$ + text$: NEXT
  3. de$ = _DEFLATE$(text$)
  4. PRINT LEN(de$), LEN(text$)
  5. PRINT de$
  8. o$ = _INFLATE$(de$) 'Note:  use _INFLATE$ optional's parameter if we know the size of the original text to get it back properly.
  9. '                                When saving your compressed data, it's probably a wise idea to save it with the legnth
  10. '                                before the compressed information, like most archives, images, ect does.
  11. '                                Just:
  12. '                                PUT #filehandle, ,OriginalSize
  13. '                                PUT #filehandle, ,CompressedString
  15. PRINT LEN(o$), LEN(text$)
Title: Re: Steve64 Repo
Post by: SW on August 19, 2019, 05:45:58 am
thanks for adding default compression in QB64.
But it bit outdated. What about something better... like LZ4 ?
Title: Re: Steve64 Repo
Post by: SMcNeill on August 19, 2019, 06:47:28 am
Quote from: SW on August 19, 2019, 05:45:58 am
thanks for adding default compression in QB64.
But it bit outdated. What about something better... like LZ4 ?

Zlib is used with/in libpng, which is what I actually need it for — PNG file creation.  All that’s left for me, at this point, is adding the CRC and Adler functions into the language for us, and then I’ll be done and moving on to other things in the near future.  ;)

Feel free to use the history of my repo as a means to help import whichever library you require for your own needs.  The process wasn’t as difficult as I’d first imagined it would be.  ;)
Title: Re: Steve64 Repo
Post by: RhoSigma on August 19, 2019, 07:07:24 am
Steve,
thanks for considering and finally make the "original size" argument optional, guess 10mb will be sufficient for most things people will do with QB64.

Are you willing to merge all these great enhancements in your personal QB64 copy into the official repo anytime?

After you posted the basic instructions for adding new commands into the language in the other thread, I was thinking about adding my HSB/HSV colorspace stuff into QB64, which is now only available in my Library collection. However, I will probably contribute to the official repo. For sure it's easily possible to have more QB64 copies on the drive, and all will coexist each in its own folder, but after already having a couple of them (eg. the original v0.954 SDL, another SDL which I've fixed a little bit by backporting enhancements/fixes done in v1.1-v1.3, your SDL v0.954e?, the official v1.3 and the actual dev build), it becomes hard to remember all the specialties in each version, so it would be reasonable to bring the changes into the official repo once upon time.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 19, 2019, 07:23:42 am
10mb is the starting size I chose for the buffer, but it’ll resize as needed to uncompress larger things.  It just won’t be very efficient at it; so it’s probably best to store the size yourself, for larger files/blocks of memory.

I’ll be happy to push changes into QB64 repo so everyone can use these commands, but it’d be nice to get them working for Linux/Mac as well, first.  I can run Linux in a virtual machine, and test things for it, but I don’t have any means to test anything for Mac.  When adding to the official version of QB64, we try and make certain everything works cross-platform, as much as possible, so it might take a while before the changes are actually merged into the development build (and later become part of the next official build). 

Eventually, I imagine we’ll see the changes merged in “official” QB64, but I wouldn’t hold my breath expecting to see them incorporated overnight.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 19, 2019, 04:31:11 pm
Pushed a few more things into my repo, mainly to customize how it behaves for me. 

Added $REPLACE into the language, as a quick typing replacement function.  Only affects the IDE itself; has no actual effect on any programs.  It can safely be removed from any program and will change functionality ZILCH...

So what's it do?

First, set a quick code for typing something:

Code: [Select]
$REPLACE ?? = _PRINTSTRING(
Then type something using that code:
Code: [Select]
??10,10), "Hello World"
The moment you hit enter, that code will magically change to become:
Code: [Select]
_PRINTSTRING(10,10), "Hello World"
With excessively long commands, or type names, it can be a complete lifesafer in terms of knuckle stress and typing needed to work on a program.

Just one cavet:  Be careful what you set as a replace code.  With the above, typing in, PRINT "What's your name??" would instantly turn into PRINT "What's your name_PRINTSTRING(".   

Usually I'll just make a quick replacement with q(number).   

$REPLACE q1 = MyVariableWithALongArseName.
$REPLACE q2 = AnotherLongArseNamedVariable.

Then I can type in:

q1x = q2x + 1

And it'll become:

MyVariableWithALongArseName.x = AnotherLongArseNamedVariable.x + 1

That's a ton of typing to save!


Also added _BORDERWIDTH and _TITLEBARHEIGHT, so we can get the value of these elements, if we ever want them
_BORDERWIDTH is, oddly enough, the width of the border of our screen, while _TITLEBARHEIGHT gives us the height of our titlebar.  Works in both Linux and Windows, though I don't know about Mac.


Altered _INSTRREV so it terminates at 0, instead of going into an endless repetitive loop.


I don't know if anyone else will ever take advantage of these enhanced (at least I think they are) features, but they're in there, so I thought I'd share here and let folks be aware of them so they can decide for themselves if they want to make use of them or not. 
Title: Re: Steve64 Repo
Post by: SMcNeill on August 19, 2019, 04:51:18 pm
Marked a post “best answer”, to highlight the differences in my person repo, and the standard QB64 version.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 21, 2019, 05:13:12 pm
Just pushed a start of changes to enhance console functionality for Windows users.

CSRLIN support added.
POS(0) support added.
LOCATE support added.
tab() glitch fixed.


Altered _PUTIMAGE so _DEST and _SOURCE handles can now be the same without any error messages.


As time allows, I plan to continue to expand console functionality, so unless you just have unlimited bandwidth and like to stay 100% current on changes, you might want to wait a few days to get another copy of the repo.  More changes are coming soon(tm).
Title: Re: Steve64 Repo
Post by: SMcNeill on August 22, 2019, 02:18:29 am
Console support extended:

LOCATE now works, as it should, with optional parameters. 
COLOR has now been implemented into the console.

(Again, for Windows-only.  I don't know if Linux/Mac even have the same console as on windows, but I know for certain these commands won't work for them, as they rely on Windows API calls and such.)
Title: Re: Steve64 Repo
Post by: SMcNeill on August 23, 2019, 01:51:16 pm
Personal Rant:  The &#!@%!! SCREEN command is a BLEEEEPING BLEEP BLEEP!!!  It can bite my little BLEEPING BLLEEEP BLERP!!  I HOPE TO NEVER HAVE TO TAKE ANOTHER LOOK INSIDE THE BLEEPING BLEEPING BLORKING BLAAARF THAT IT IS, EVER AGAIN!!!

And, with that informative rant said, I now have SCREEN support enabled for the CONSOLE.

_SCREEN (x,y,0) returns the ASCII character value of point (x,y) on the console. 
_SCREEN (x,y,1) returns the COLOR character value of point(x,y) on the console.

NOTE: This requires that you set your source to the console, so SCREEN knows where to look for information.  For example:

$CONSOLE
_CONSOLE ON
_ECHO "Hello World"
PRINT "Screen can bite my hiney!"
PRINT SCREEN(1,1,0)

With the above, what is the screen command going to print for us?  The information for the screen, or the information for the console??

With no _SOURCE set, it's going to print the ASCII value for "S" -- the character on the screen.

If you want to get the value for the console, simply set the source to console first, as so:

$CONSOLE
_CONSOLE ON
_ECHO "Hello World"
PRINT "Screen can bite my hiney!"
_SOURCE _CONSOLE
PRINT SCREEN(1,1,0)

Note 2:  Most of these commands require _DEST or _SOURCE to be set to _CONSOLE before calling them, so you can differentiate between the console and screen with them.


Upcoming next is the _NAME_TO_BE_DETERMINED command to allow us to get single keystrokes from the console, without having to depend on ENTER being an input terminator.  This one isn't one that fits nicely into any of the existing commands, as it behaves much differently than INKEY$ or _KEYHIT.  For one thing, it's STILL a function which pauses program execution when it's called -- it doesn't return a "" or 0 as a NULL return.  As a second point, it returns a different set of scan codes than INKEY or _KEYHIT uses...

For the codepage which the  _NAME_TO_BE_DETERMINED command uses, take a look at the page here: https://www.qb64.org/wiki/Keyboard_scancodes and scroll down to the INP Scan Codes heading and view them. 

As for the name of this command, I'm thinking _CONSOLESCANCODE seems rather longish to me, and _CONSOLEINP seems a little goofy, as if somebody forgot to add an UT to the end of the INP..  I'd like a command name that is both descriptive and not so long to type over and over...

_CINP may be the name I go with, as this is very similar to a _CONSOLE version of the INP command, but I'm open to any suggestions.  As long as I'm still developing and pushing things into my personal repo, nothing is set in stone, so a name change can happen at any time, if anybody has a nice suggestion for me.  Just give me a good idea for what to call the command, before I end up pushing all these changes into QB64's development repo.  ;)
Title: Re: Steve64 Repo
Post by: SMcNeill on August 23, 2019, 03:12:04 pm
Took a quick moment to add support to _WIDTH and _HEIGHT so we can now know the size of our console. 

Oddly enough, a default console has a height of 300, with only 25 lines actually visible at a line.  The other 275 lines are stored in a buffer so we can scroll back and take a look at them...

Who knew?!!

I'm not one to do too much work with the console, but looking into it, it's not really that hard to change the parameters on both that buffer amount, and the visible amount both...

The issue is...

We can't get that many parameters into our existing WIDTH command!

Currently I've got it set up so we can use WIDTH to set a width/height, but it makes the buffer size the exact same size as the view size.  Take the command WIDTH 120,50 for example -- it'll give us a console 120 characters wide (instead of the standard 80) and 50 lines high (instead of the normal 25), but it'll also currently make our console buffer that same 120x50 in size.  No scrolling up to see what ran off the screen, if you use my current implementation of WIDTH for the console!

And I'm not certain if I like that too much, but there's not much I can do if I stick with the current WIDTH command for things.  The options as I see them are:

1) Use WIDTH, as it currently exists, and make the buffer the same size as the view screen. (My current implementation.)

2) Change WIDTH so that it has two new parameters for the buffer width/height.

3) Create a brand new command with 4 parameters (width, height, buffer_width, buffer_height) so we can pass all the relevant information back and forth to the console. 

EDIT: Option 4) Leave the new window with a 300 line buffer that we can use to scroll up and down, the same as always, with no means to disable it, or increase/decrease it.

So my first question is:  How would you guys like to see me deal with the console width and height, and the separate console buffer width/height?

Second question:  Do I need a _CONSOLEBUFFERWIDTH and _CONSOLEBUFFERHEIGHT command as well, or are we good without one?
Title: Re: Steve64 Repo
Post by: FellippeHeitor on August 23, 2019, 03:32:15 pm
If 300 lines of buffer is default, I say keep it.

I vote for maintaining it all under WIDTH too.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 23, 2019, 05:17:03 pm
Quote from: FellippeHeitor on August 23, 2019, 03:32:15 pm
If 300 lines of buffer is default, I say keep it.

I vote for maintaining it all under WIDTH too.

I think I've settled on the way I'm going to work things; I've just added 2 new optional parameters to the existing WIDTH command so we can pass the buffer width and height via it.  It won't affect any existing code one bit, but it expands the functionality so we can customize the size of our console however much we want it.

Changes have been pushed into my repo which support _WIDTH and _HEIGHT with _SOURCE _CONSOLE set (which I kept forgetting to do when testing things, making myself think over and over that I'd broken code which was working just fine -- except for the idiot behind the keyboard!)

WIDTH now has two more optional parameters which we can use to set the buffer width and buffer height of the console and it works with _DEST _CONSOLE (which is part of the problem with my own testing, as I will sometimes set one and forget the other...).

Anyone have any decent suggestions for the name of the input routine?  I was kinda playing around with WIDTH/HEIGHT while seeing if anybody had any suggestions, but noone has spoken up yet with one...  If nobody has any better names, there'll be a new keyword coming to the language called _CINP, which we can use to get single character input from the console. 


The more I work with upgrading the console functionality, the more I wonder why anybody ever bothered to use it in the past.  Everything seems glitchy or non-implemented, and I don't know how anybody ever managed to code in $CONSOLE:ONLY mode.  Heck, even SLEEP doesn't work properly!  (And I'll work on fixing it for us, after I get _CINP implemented sometime soon(tm).)
Title: Re: Steve64 Repo
Post by: bplus on August 23, 2019, 06:09:28 pm
_CKEY ? because similar to INKEY$
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 03:51:59 am
Added lots of new functionality to my repo for Windows users. (Sorry Linux/Mac folks, these rely on windows API calls, and I don't do enough {read any} programming in Linux or Mac, to know the equivalent versions to implement this functionality for your systems.   Maybe Luke and Fellippe will add the Linux/Mac versions for you folks later.)

For starters, we now have _CINP(optional toggle) to get single key presses from the console for us.  I've explained the routine several times in the past, and folks can test its behavior with the DECLARE LIBRARY version of this command here: https://www.qb64.org/forum/index.php?topic=1540.msg107963#msg107963

The toggle is optional and changes from what I think is a simplified code value set (negative values for up events, positive values for down events), to the standard version (+128 to keypress code for up event, standard keypress code for down event). 


Added several new commands which I feel could be quite useful with this command:

_CAPSLOCK, _NUMLOCK, _SCROLLOCK -- to get the value of these keyboard states for us.  Returns 0 if they're off, 1 if they're on.

_TOGGLE_CAPSLOCK, _TOGGLE_NUMLOCK, _TOGGLE_SCROLLOCK -- to change the keyboard state for these keys, if we choose to.  NOTE: This is a global keyboard change, and *WILL* affect typing in other programs as well.  If CAPSLOCK goes on or off on your keyboard, it changes the input for everything we type with our keyboard; not just what we type into one program.


Quote from: bplus on August 23, 2019, 06:09:28 pm
_CKEY ? because similar to INKEY$

I just stuck with _CINP as it's (almost) a console version of INP.  It's good enough for me, and can always be changed later, if folks have a better name for it, before I push any of these changes into the official repo.


And what's left to do at this point??

I still know that SLEEP needs to be altered to work with the console, and now that we have func__CInp built in for windows, that shouldn't be any issue to fix.  Also END needs the same overhaul so we get back to "Press <ANY KEY> to close", rather than "Press <ENTER> to close".

Otherwise, I think I'm nearing the end of this series of changes (after all, I'm not a console user normally anyway), so unless you guys know some console functionality that doesn't work, or some functionality which needs to be added, I'll probably be wrapping up this series of changes/enhancements later today or tomorrow for us.  :)
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 05:06:40 am
Added support for SLEEP, CLS, END to all work properly with the console.

And, I think I'm done with adding console support to QB64.  I don't use it enough to know what I'm missing, so if you guys see functionality missing that you think the console needs, post and let me know.  I'll see what I can do to add it to the language for us.
Title: Re: Steve64 Repo
Post by: Petr on August 24, 2019, 12:45:03 pm
Hi. I have one question about the console, I don't know if that is the intention or why it is, it is about the sound phrase when using sound commands with _CONSOLE. Why is it there?

  [ This attachment cannot be displayed inline in 'Print Page' view ]  
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 01:40:40 pm
Quote from: Petr on August 24, 2019, 12:45:03 pm
Hi. I have one question about the console, I don't know if that is the intention or why it is, it is about the sound phrase when using sound commands with _CONSOLE. Why is it there?


No idea.  I don't get it when I run the test code that you are.  For some reason, it appears the sound library is tossing an error message of some sort out for you, but I have no idea why or what it is.  I haven't tried to dig into anything at all sound related yet.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 02:11:36 pm
Pushed a fix to the repo, where I'm basically an idiot...

When testing the new features, I inserted some breakpoints into the code, to rule out problem areas from consideration...  Like a dummy, I left one of those in there, completely breaking comma delimited text while in graphics modes.  That issue should be corrected now.  (It was all of removing on "return;" from the code...)  /sigh

It's always something!
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 07:26:17 pm
Forgot a big part of the console changes which I wanted to bring -- the ability to change the font itself inside the console!

Added a new command to allow us to do this:  _CONSOLEFONT (fontname$, size)

Usage is rather simple, as: 
Code: QB64: [Select]
  3. _CONSOLEFONT "Courier New", 16 'change default size to 16, with Courier New font
  4. PRINT "Hello World"
  6. _CONSOLEFONT "", 24 'change default size to 24, without changing the font itself.
  7. PRINT "Hello World"
  9. _CONSOLEFONT "Consolas", 24 'change default size to 16, with weirdo Consolas font.
  10. PRINT "Hello World"

Note, this doesn't return any sort of error code for us in case it fails, and I have no idea how the BLEEP you can actually determine what the actual fonts are which work with the console.  The way I got these names was to open up a console window of my own, right click on the title bar, select PROPERTIES, and then FONT, which at that point I just chose two which were easy enough to spell, and different enough to tell apart with my console.  These fonts may, or may not, be on your PC -- I dunno!!  As I've said before, I'm not a regular user of the console for many things, so I'm sort of stumbling around in the dark trying to piece all these parts together to get them to work for us...

Apparently though, there doesn't appear to be much need for an error message, as the console basically just seems to ignore an unrecognized parameter (such as the blank font name I tested above).  All I can say at this point is test it out, beat it around, and if it does crash or do something completely insane, let me know and I'll try and dig further into the documentation and see if I can sort out what went wrong and how to correct it in the future.
Title: Re: Steve64 Repo
Post by: SMcNeill on August 24, 2019, 07:52:12 pm
I told you guys that you might want to hold off for a few days while I was working on adding all the little changes to the repo, but I think I'm finally finished with pushing things into the repo for a bit.  I think I'm going to take a break for several days and give folks time to test everything out and see if anything appears broken, or not to work for them, and use the opportunity to catch up with my deadline for my newest novel. 

Post any thoughts, questions, feedback, and concerns below, and I'll see what I can do about addressing it ASAP, but don't expect to see anything  new added to the repo for a bit.  I'm (semi) on coding vacation now, for the next few weeks, as I catch up with other stuff in life!  ;D
Title: Re: Steve64 Repo
Post by: SMcNeill on August 25, 2019, 09:53:52 am
And just when I'd thought I'd finished, I decided to take a look back at the Windows console library which I'd shared earlier, and I'd noticed that I'd forgotten a tool folks might like -- the ability to hide or show the console cursor.

So...

I went and added it.  Heck, I went a step further and even made it sizeable!

One last, new, command added:  _CONSOLECURSOR _SHOW|_HIDE, cursorsize

Usage would be like the following:
Code: QB64: [Select]
  3.  
  4. FOR i = 100 to 0 STEP -10
  5.     _CONSOLECURSOR , i 'set it to i% size
  6.     PRINT "Hello World"
  7.     SLEEP 'pause so we can see it.
  9.  
  10. _CONSOLECURSOR , 100 'set it to 100% size so it's nice and visible
  12.  
  13. _CONSOLECURSOR _HIDE 'hide the cursor
  15.  
  16. _CONSOLECURSOR _SHOW 'show the cursor
  18.  

Both parameters are optional, but if you call it without setting either, the world might be destroyed by your computer's laughing at you...

Title: Re: Steve64 Repo
Post by: SMcNeill on August 26, 2019, 09:26:42 am
Added mouse support for the console.  I’m off to town with the wife, so will document it later, but you can see an example of the mouse working in the console in the demo I just posted earlier.  ;)
Title: Re: Steve64 Repo
Post by: bplus on August 26, 2019, 12:41:44 pm
OK now I am trapped, a scrolling screen PLUS mouse access along with all the other basics, wow Steve!
Title: Re: Steve64 Repo
Post by: SMcNeill on August 26, 2019, 12:47:00 pm
Quote from: bplus on August 26, 2019, 12:41:44 pm
OK now I am trapped, a scrolling screen PLUS mouse access along with all the other basics, wow Steve!

If you're testing it out, stop by the IRC chat channel and join us, while we try and debug any issues which might pop up with things.

http://www.qb64.org/ircpage.html
Title: Re: Steve64 Repo
Post by: SMcNeill on September 17, 2019, 06:59:21 pm
Added an option into the QB64 IDE which allows us to Ignore Warnings.
Title: Re: Steve64 Repo
Post by: Cobalt on September 21, 2019, 06:03:30 pm
Excellent!
 Why was the Warning thing added to the IDE in the first place, may I ask?

I find it very distracting.
Title: Re: Steve64 Repo
Post by: FellippeHeitor on September 21, 2019, 06:16:38 pm
My request and implementation.
Title: Re: Steve64 Repo
Post by: SMcNeill on September 21, 2019, 06:29:38 pm
Quote from: Cobalt on September 21, 2019, 06:03:30 pm
Excellent!
 Why was the Warning thing added to the IDE in the first place, may I ask?

I find it very distracting.

Mainly as a compromise amongst the folks who work the most on developing QB64.  I brought up the idea that we really didn't need to toss errors when a CONST was set multiple times inside a program.  (Such as having CONST TRUE = -1, FALSE = 0 inside multiple library files which used to toss an error for multiple occurances.)  I figured, "Who cares if a CONST is declared over and over, as long as the VALUE remains the same?  We only really need an error when the values don't match."

After all, why would this toss an error?

CONST True = -1
CONST True = -1
CONST True = -1

True starts out -1 when we first type it.  It stays -1.  So why the heck do we actually need to stop compilation of the program and claim it's an error?  (Especially when "True" itself never appears anywhere in the C-code we generate, as we substitute the value -1 everywhere it appears in our code.)

I thought we should just ignore multiple instances, as long as  the values match.  Fellippe didn't want to break from the tradition of BASIC and wanted to keep the error message to make the programmer delete one of those values.  In the end, we settled on a middle ground compromise -- toss a warning to let folks know that they have more than one CONST with the same name and value, but don't actually stop compilation of the program. 

And, once the system was in place, it's usage has expanded to now toss warnings for various other things as well (such as for unused variables.)

But, like you, I just find the system to be a distraction.  There's even edge cases where I get warnings for "variables not in use", when the are, in fact, in use, (I think its a case where you define a variable, but only reference it via _MEM and not directly,  where I found this happening,) which either requires writing drivel code somewhere to shut up the warning system (foo = foo), or it means it's always going to be a warning message down in the bottom of the IDE to drive you batty...

So, a solution came to me:  Place a toggle in the IDE and let folks freely ignore those warnings, or not, as whichever method suits their preference.  (You can certainly bet that my personal version has it toggled on all the time now.  ;D)

IF nobody finds or reports a glitch in how it makes their programs work, I'll push the changes into the development build for widespread testing and usage there, and then we'll see that option full time in the next stable release which comes out (whenever that happens).

Title: Re: Steve64 Repo
Post by: Cobalt on September 21, 2019, 10:37:57 pm
Ahh, now I know.
 I was curious why there wasn't a toggle for it already, most of the other additions to the IDE can be turned on or off. I guess if you really REALLY wanted clean code in the end it would be helpful, though I don't know, can you even click on the warning to see whats causing it?

guess you can.
Text Only | Text with Attachments