But it is definitely very sad to have to type own keyboard solution. But I believe that if you combine INKEY$ and _KEYHIT, you would probably achieve the same effect. Or really not?
I didn't want to jump off topic from my little splash screen demo just to talk about the differences in keyboard handling routines, so I thought I'd hold his discussion here.
To follow along with what I'm illustrating, grab the two attachments below and put them in your QB64 program, and then you can run the following code:
'$INCLUDE:'Keyboard Library.BI'
k = KeyHit
'$INCLUDE:'Keyboard Library.BM'
Now for our first test, test a simple little CTRL-TAB:
CTRL-TAB
100306
-105
-100306
-17
27
-27
------
100017
100306
9
-9
-100017
-100306
Now, run the same program once again, only this time you want to hit CTRL-I:
CTRL-TAB
100306
105
-105
-100306
-17
27
-27
------
100017
100306
105
-105
-100017
-100306
Take a moment and compare the results.
With TAB:
For _KEYHIT, we don't have a positive keydown code, but we have a key-up code of -105.
With KeyHit, we have codes of 9 and -9.
With I:
For _KEYHIT, we have codes of 105 and -105.
With KeyHit, we have codes of 105 and -105.
So with _KEYHIT, we can't even generate a key down event for CTRL-TAB, and our key up code is the one for CTRL-I instead!!
Run the same test again, and this time all you want to do is simply hit the CAPSLOCK key for both routines:
CTRL-TAB
-100301
-20
27
-27
------
100301
-100301
Now for QB64, we get some really mixed results for this key with _KEYHIT. On one hit, we get a value of -100301 for when we press the key down. On the next hit, we get a value of +100301 for the same key down. It all depends on if _CAPSLOCK = TRUE or not. And, for some odd reason, we have a key up code of -20??
With KeyHit, from the library, we get a sensible 100301 for key down and -100301 for keyup, regardless of whether _CAPSLOCK is up or down.
And these are just two of the many differences between the two routines. QB64 has some serious failure in its built-in keyboard scan codes. For most applications, where all you have to worry about is an user typing in A-Z and 0-9 type keys, they work fine. (If they didn't, our boards would be full of bug reports on the issue, and most people have no clue how badly those commands actually fail to work properly.)
For my game, I'm allowing the user to assign keys to whatever mapping they want on their keyboard, so I have no idea if somebody, somewhere, might want to use CTRL-TAB to swap weapons and CTRL-I to open their inventory... If they do, I need to be able to read each of those as independent keystrokes and not have them return the same values, so I wrote my own keyboard library which completely ignores QB64's flawed input routines. Honestly, as one of the guys who helps contribute to the QB64 source, I'd swap our existing _KEYHIT out for this KeyHit, except for one big thing:
I'm just a Windows-guy. This relies on the windows API calls to work and won't work in Linux or Mac, and I have no idea about their internal keyhandling routines to even start to make it work for them.
In my opinion, KeyHit is leagues better than _KEYHIT for Windows, but unfortunately, it doesn't work at all for Linux or Mac users.
