INKEY$ doesn't work with fixed length strings

[justsomeguy]

As an addendum to my prior post. https://qb64phoenix.com/forum/showthread.php?tid=2889

If I attempt to use INKEY$ with a fixed length string I get no values.

Here is an example:

Code: (Select All)

TYPE tt

' Use 2 bytes to capture 2 byte combinations

'k AS STRING ' Works

k AS STRING * 2 ' Does Not work

END TYPE



DIM AS tt t



DO

t.k = INKEY$

LOCATE 1, , 1

PRINT "k:"; t.k

LOOP

It doesn't appear to matter how many bytes I allocate, It does not work.

I know there are many workarounds, like using _KEYHIT, or not using fixed length strings.

Again, I'm on Linux using QB64pe v3.13

[DSMan195276]

I think your program is just running too fast for the character to appear on the screen. Keep in mind that a fixed length string is never empty, so when you do the `PRINT` it will always put out two characters when printing the string. NUL bytes (CHR$(0)) will fill the fixed-length string when nothing was returned by INKEY$ and when printed those appear like a space, so they will overwrite whatever was previously on the screen.

[SMcNeill]

Works as expected. Try this:

Code: (Select All)

TYPE tt

    ' Use 2 bytes to capture 2 byte combinations

    'k AS STRING ' Works

    k AS STRING * 2 ' Does Not work

END TYPE



DIM AS tt t



DO

    t.k = INKEY$

    PRINT "k:"; t.k

    _limit 10

LOOP

The issue is you're printing it in an loop. You press "A", it pops up on the screen for a poop, and then the loop just keeps repeating, and it's replaced almost instantly by nothing as it waits for the next keypress to poop up the next key being processed.

[TerryRitchie]

I hate it when my "A"s poop on the screen!

[justsomeguy]

I see thank you!

[bplus]

I hate it when my "A"s poop on the screen!

I hate it when my "A"s poop in my shorts.

TMI?

[Pete]

Works as expected.  Try this:

...

The issue is you're printing it in an loop.  You press "A", it pops up on the screen for a poop, and then the loop just keeps repeating, and it's replaced almost instantly by nothing as it waits for the next keypress to poop up the next key being processed.

Wow, missing out on that porta-potty contract is really eating at you!

Pete  

- I'm in with the INKEY$ crowd!

EDIT: @justsomeguy

I don't use a dim as string approach with INKEY$, I noticed this approach makes a null string as CHR$(32) + CHR$(32). That will be problematic if you intend to trap a spacebar press.

Code: (Select All)

Type tt

    ' Use 2 bytes to capture 2 byte combinations

    'k AS STRING ' Works

    k As String * 2 ' Does Not work

End Type



Dim As tt t



' Note you cannot detect a spacebar press with this 'Dim as String' approach.

Do

    t.k = InKey$

    If Len(LTrim$(t.k)) Then

        Locate 1, 1

        Print "k:"; t.k, Asc(Mid$(t.k, 1, 1)), Asc(Mid$(t.k, 2, 1)); "  "; ' Cover up larger output strings.

    End If

Loop

[justsomeguy]

Works as expected.  Try this:

...

The issue is you're printing it in an loop.  You press "A", it pops up on the screen for a poop, and then the loop just keeps repeating, and it's replaced almost instantly by nothing as it waits for the next keypress to poop up the next key being processed.

Wow, missing out on that porta-potty contract is really eating at you!

Pete  

- I'm in with the INKEY$ crowd!

EDIT: @justsomeguy

I don't use a dim as string approach with INKEY$, I noticed this approach makes a null string as CHR$(32) + CHR$(32). That will be problematic if you intend to trap a spacebar press.

Code: (Select All)

Type tt

    ' Use 2 bytes to capture 2 byte combinations

    'k AS STRING ' Works

    k As String * 2 ' Does Not work

End Type



Dim As tt t



' Note you cannot detect a spacebar press with this 'Dim as String' approach.

Do

    t.k = InKey$

    If Len(LTrim$(t.k)) Then

        Locate 1, 1

        Print "k:"; t.k, Asc(Mid$(t.k, 1, 1)), Asc(Mid$(t.k, 2, 1)); "  "; ' Cover up larger output strings.

    End If

Loop

You make a good point. I wonder why this is the way it works. It would make more sense to be filled with NULLs than spaces.

It would be also nice, that we have new LEN() function that returns the actual length of the string.

[SMcNeill]

Wouldn't _KEYHIT simply be easier for this?

INKEY$ returns a 1 or 2-byte string value for user input.  _KEYHIT returns that *exact* same value, except in Integer form, rather than string.  You can easily convert between the two with the MKI$ and CVI commands.   It just seems to me if you're always going to be dealing with 2-byte strings, that it'd probably just be more efficient overall to just use the integer values.  There's always extra overhead when dealing with strings, and they're always slower than integers to process and handle, so I'd honestly just _KEYHIT over INKEY$.

[bplus]

It would be also nice, that we have new LEN() function that returns the actual length of the string.

What! ? did someone not renew our license to Len()

Wouldn't _KEYHIT simply be easier for this?

yeah! and do you know that under IDE Menu > Tools > Insert Quick Keycode
you can insert the Keycode quickly, no number lookup!

Can notepad++ do that? ;-))