A few pushes to the Development build

[SMcNeill]

Using your first sample code there is a problem. To best illustrate, I'm adding a single line of code at the end so that you end up with this:


$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE

PRINT "Foo"

t# = TIMER
SLEEP 2
PRINT USING "##.### seconds"; TIMER - t#
INPUT "Enter some text: ", Text$

This isn't a glitch introduced with the latest changes to the routine; it was one which was there even before.  I'm digging into it.

[SMcNeill]

Using your first sample code there is a problem. To best illustrate, I'm adding a single line of code at the end so that you end up with this:


$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE

PRINT "Foo"

t# = TIMER
SLEEP 2
PRINT USING "##.### seconds"; TIMER - t#
INPUT "Enter some text: ", Text$


If allowed to run with no user input, it runs just fine. However, if you press a key during the 2 second pause the program advances as expected without waiting for the 2 seconds, but when it reaches the input statement note that as you try to type you see no characters displayed. You have to press ENTER twice to get past the input statement.

I experience the same problem with the second sample where I again add the input statement:

$CONSOLE:ONLY
_DEST _CONSOLE: _SOURCE _CONSOLE

PRINT "Foo"

SLEEP
INPUT "Enter some text: ", Text$

This glitch here is a screen flag setting.

For whatever reason, QB64 doesn't initially enable our window to work with mouse input.  Since mouse support is something I added when I added the single character input routines, I had to go in and enable it for us, which was done via this little snippet:

Code: [Select]

        fdwMode = ENABLE_EXTENDED_FLAGS;
        SetConsoleMode(hStdin, fdwMode);
        fdwMode = ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT;
        SetConsoleMode(hStdin, fdwMode);
Basically, tell the console that I wanted window input and mouse input...

BUT, the problem was, I wasn't accounting for the flags which were normally set for the console window (like ENABLE_ECHO_INPUT).  When you called the single key routine, permissions with the window were changed, and it wouldn't echo text back on it anymore...

Fix to this appears to be rather simple..ish:

Code: [Select]

        GetConsoleMode(hStdin, (LPDWORD)&dwMode);
        fdwMode = ENABLE_EXTENDED_FLAGS;
        SetConsoleMode(hStdin, fdwMode);
        fdwMode = dwMode | ENABLE_WINDOW_INPUT | ENABLE_MOUSE_INPUT;
        SetConsoleMode(hStdin, fdwMode);
Get the old console flags, use them as the standard base of flags for the screen, and enable the mouse input with them....

Initial testing shows that things appear to be working without any glitches, but I wouldn't swear to it without further testing.

Grab the libqb.cpp below, follow the instructions with the previous post to place it and purge the old library, and test the heck out of it.  Any glitches found now are ones which I won't have to try and address later, after I've forgotten exactly what the heck I've done so far with the source...

As far as I can tell, everything passes muster -- mouse input, single character input, INPUT$, and SLEEP.  If something is off, just let me know and I'll see about addressing it and correcting the problem.

[hanness]

I've done some quick initial testing, and so far, so good. I'm going to test more extensively but it may be tomorrow before I have opportunity to do so.

[SMcNeill]

Pushed the changes to SLEEP into the development build.  You should now be able to use it in the console along with a TIME limit -- many thanks to Ed Davis for helping show me the command I need to accomplish this! 

Also added functionality for _KEYCLEAR to work with regards to Windows Console, so you can now use it to flush the input buffer.  One thing to note here:  The console input buffer contains *ALL* input which the system has for the console.  When you _KEYCLEAR the buffer, you're also going to clear the mouse buffer as well, as they're inevitably one and the same.  I don't think it'll actually affect anything for folks using it, but I felt it was better to mention this quick of usage than to not mention it.  If it ever does seem like you're losing mouse input events, it may be because you have a _KEYCLEAR command in your mouse handling loop -- and I don't think that'll work as intended at all for you!

The console isn't set up quite the same as our normal screen is, and the mouse and keyboard are irreversibly linked together.    When we read input events, we read both the mouse and keyboard together.  (Which is why we need to call _CONSOLEINPUT to see what type of input we're getting -- mouse, keyboard, or something else oddish.)  By the same token, when we clear one buffer, we're also going to clear the other.

Just be aware of this slight difference with _KEYCLEAR and the console input buffer.  ;)

[RhoSigma]

Any work done on the &B prefix stuff mentioned here ?
https://www.qb64.org/forum/index.php?topic=1933.msg111816#msg111816

If not, I could do it. Just finished and tested the necessary changes within my old SDL version, but when looking on the same routines in the current version it seem they haven't changed since the old SDL days, so I could easily transfer it and then make a commit/pull request to/from my repo.

Just let me know, if Im not to late and the work is already done maybe.

[FellippeHeitor]

Hasn’t been done yet. Please add the pull request.

Make sure to work on the latest dev branch.

[RhoSigma]

Done, pull request is ready for approval.

[FellippeHeitor]

Sent a reply.

[RhoSigma]

Sent a reply.

Did too...

[FellippeHeitor]

PR Merged.

[RhoSigma]

PR Merged.

Thanks Fellippe,

So to announce this for everybody,
with the dev builts starting from today we have extended the recognition of binary number strings (prefix &B) to the INPUT command and to the  READ/DATA commands.

INPUT "Number:"; num
will allow typing &H, &O, and now also &B numbers at its prompt

INPUT #1, num
will allow reading of &H, &O, and now also &B numbers from files

READ hexNum, decNum, octNum, binNum
DATA &HFF, 255, &O377, &B11111111
will now work as expected and without throwing a "Syntax Error" on the binary number

Of course, the case of the H/O/B letters doesn't matter.
This addition completes the support for &B usage, which was already introduced a while ago for the VAL function.

As a remainder for those, who didn't know yet, just as &H/&O, it is also possible to use &B numbers in regular calulations such as X = (34 + &B1101) / &H10 and as arguments for SUB/FUNCTION calls eg. X = Foo(&B1011) or indicies for arrays eg. Num(&B11) = 3. This is the oldest support for &B and was already built into the ancient SDL versions of QB64.

[SMcNeill]

Question:  Does the changes affect LINE INPUT as well?

[RhoSigma]

Question:  Does the changes affect LINE INPUT as well?

No it doesn't, LINE INPUT allows for string variables only, hence it doesn't need to do any internal string/number conversion, it just reads a string as is. If you want a number, then you've to pass the input string variable thru VAL() after the input.

[FellippeHeitor]

As per the wiki.

[RhoSigma]

Pushed an option into the IDE today so you can toggle to Ignore Warnings on and off.   (Variable not defined, or CONST name already in use warnings.)

Either I got this wrong or it doesn't work as it should.
Even with the "Ignore Warnings" option enabled I get the warnings and the code don't get auto-formatted and I'm not able to run(F5)/compile(F11) the program until either commenting the OPTION _EXPLICIT line or add a DIM for the variable.

EDIT:
And why does changing the "Show Compilation Errors Immediately" or "Ignore Warnings" toggle also set the state of the currently loaded program to "changed"? (it gets the * added to its title, and the IDE will ask you to save when quiting).