Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: doppler on July 25, 2019, 06:47:32 pm

Title: Not so much a bug but inconsistent
Post by: doppler on July 25, 2019, 06:47:32 pm
This is not much of a bug like the subject line says.  It's part of the extended QB64 functions so we can just say.  "That's how it's gonna work."

If function "END" is use the program would ask to "Press any key to continue".

What's inconsistent:

$CONSOLE:ONLY
_ECHO "Hello"
END

The program ends with message "Press enter to continue".  And it really wants the enter key only.

At least the END does not multi-thread max the CPU out anymore.  That was an old ending bug.
And YES I want to use the END function, otherwise the window would just go whizzing on by too fast to
read and scrollback later.

So which one do we got here, is it a BUG or Feature ?
Title: Re: Not so much a bug but inconsistent
Post by: FellippeHeitor on July 25, 2019, 07:32:48 pm
Not a bug or feature, but a workaround. We can’t read inkey$ in the console, so the way to trigger a pause is to wait for input. ENTER marks the end of user input (notice you can still type while the message is displayed).
Title: Re: Not so much a bug but inconsistent
Post by: doppler on July 25, 2019, 08:18:59 pm
Quote from: FellippeHeitor on July 25, 2019, 07:32:48 pm
but a workaround

So,

Quote from: doppler on July 25, 2019, 06:47:32 pm
"That's how it's gonna work."
Title: Re: Not so much a bug but inconsistent
Post by: SMcNeill on July 25, 2019, 09:03:18 pm
Quote from: FellippeHeitor on July 25, 2019, 07:32:48 pm
Not a bug or feature, but a workaround. We can’t read inkey$ in the console, so the way to trigger a pause is to wait for input. ENTER marks the end of user input (notice you can still type while the message is displayed).

Here's a way to read  inkey$ with console:

Step 1:  Copy the following and save it inside your QV64 folder as "Test.h":

Code: C++: [Select]
  1. extern int32 ConsoleKeyhit (VOID);
  2.  
  3. int32 ConsoleKeyhit (VOID)
  4. {
  5.   HANDLE hStdin = GetStdHandle (STD_INPUT_HANDLE);
  6.   INPUT_RECORD irInputRecord;
  7.   DWORD dwEventsRead;
  8.   CHAR cChar;
  9.  
  10.   while(ReadConsoleInputA (hStdin, &irInputRecord, 1, &dwEventsRead)) /* Read key press */
  11.     if (irInputRecord.EventType == KEY_EVENT
  12.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_SHIFT
  13.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_MENU
  14.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_CONTROL)
  15.     {
  16.       cChar = irInputRecord.Event.KeyEvent.uChar.AsciiChar;
  17.         ReadConsoleInputA (hStdin, &irInputRecord , 1, &dwEventsRead); /* Read key release */
  18.         return cChar;
  19.     }
  20.   return EOF;
  21. }

Step 2: Make use of DECLARE LIBRARY to use the command, as such:

Code: QB64: [Select]
  2.     FUNCTION ConsoleKeyhit
  4.  
  5.  
  8. _ECHO "Hello"
  10.     a = ConsoleKeyhit
  11.     IF a <> 0 THEN PRINT a
  12. LOOP UNTIL a = 27

Compile and run, and you should be able to read in the keycodes for keys one at a time as you press them, without having to wait and trap for the ENTER key for the end of input stream.
Title: Re: Not so much a bug but inconsistent
Post by: FellippeHeitor on July 25, 2019, 09:41:59 pm
Quote from: SMcNeill on July 25, 2019, 09:03:18 pm
Here's a way to read  inkey$ with console:

Thanks for sharing.
Title: Re: Not so much a bug but inconsistent
Post by: SMcNeill on July 25, 2019, 10:24:12 pm
Quote from: SMcNeill on July 25, 2019, 09:03:18 pm
Here's a way to read  inkey$ with console:

It's actually more of a way to get _KEYHIT style codes back from the console. 

Tweaking it a bit more, I find that this version of Test.h gives us better results to mimic what we'd expect to see from _KEYHIT better:

Code: C++: [Select]
  1. extern int32 ConsoleKeyhit (VOID);
  2.  
  3. int32 ConsoleKeyhit (VOID)
  4. {
  5.   HANDLE hStdin = GetStdHandle (STD_INPUT_HANDLE);
  6.   INPUT_RECORD irInputRecord;
  7.   DWORD dwEventsRead;
  8.   INT32 cChar;
  9.  
  10.   while(ReadConsoleInputA (hStdin, &irInputRecord, 1, &dwEventsRead)) /* Read key press */
  11.     if (irInputRecord.EventType == KEY_EVENT
  12.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_SHIFT
  13.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_MENU
  14.         &&irInputRecord.Event.KeyEvent.wVirtualKeyCode != VK_CONTROL)
  15.     {
  16.       cChar = irInputRecord.Event.KeyEvent.uChar.AsciiChar;
  17.       if (cChar == 0) cChar = 256 * irInputRecord.Event.KeyEvent.wVirtualScanCode; //translate to an extended ASCII value, to match _KEYHIT codes.
  18.       //NOTE: SHIFT and other modifier keys are still giving incorrect codes.  They need a little tweaking to work nicely.
  19.       if (cChar>90) ReadConsoleInputA (hStdin, &irInputRecord , 1, &dwEventsRead); /* Read key release */
  20.       if (cChar<65) ReadConsoleInputA (hStdin, &irInputRecord , 1, &dwEventsRead); /* Read key release */
  21.           return cChar;
  22.     }
  23.   return EOF;
  24. }
Title: Re: Not so much a bug but inconsistent
Post by: Ashish on July 26, 2019, 08:09:48 am
Thanks Steve. This is helpful. Why not add this as new command to QB64.
Title: Re: Not so much a bug but inconsistent
Post by: SMcNeill on July 26, 2019, 10:00:27 am
Quote from: Ashish on July 26, 2019, 08:09:48 am
Thanks Steve. This is helpful. Why not add this as new command to QB64.

It doesn't work quite as expected by trying to return _KEYHIT codes (it's an issue with knowing when to read/clear the key up press either requiring a double keypress {such as if we try ti SHIFT-ENTER}, or else returning a false double press result.)  Instead, I've tweaked it so that it works as expected, (at least as I'd expect it to), with INP Scan Codes.

To find the newest (and hopefully glitch free) version, pop over to the new topic here: https://www.qb64.org/forum/index.php?topic=1535.0
Title: Re: Not so much a bug but inconsistent
Post by: Pete on July 27, 2019, 06:53:50 am
Funny, Mike at The QB Forum had something similar to the recording key press and key release with INP(96)

https://www.tapatalk.com/groups/qbasic/returning-to-qbasic-after-so-many-years-t39527.html#p212907

Pete
Text Only | Text with Attachments