QB64.org Forum
Active Forums => Programs => Topic started by: STxAxTIC on December 22, 2020, 08:13:05 am
-
So this is something weird - I don't know if its my keyboard, or my system, or how im writing this code.... but for whatever reason, pressing Ctrl+J doesnt pick up, but Ctrl+L does.
I just need another set of eyes to look at it. This is simple to someone.
-
That is strange.
-
okay, so somehow code 13 has something to do with this?...
-
This captures it in smaller code:
PRINT "Press ENTER or Ctrl+J"
-
Alright this was solved. It happens for a reason of some kind. Work-around shall be inkey$ to catch the J.
-
CTRL+J translates into CHR$(10) for MS-DOS reasons. Read INKEY$ instead and look for CHR$(10) and you're golden.
For reference (http://www.physics.udel.edu/~watson/scen103/ascii.html (http://www.physics.udel.edu/~watson/scen103/ascii.html)):
-
Just another example of _KEYHIT and _KEYDOWN being broken. If you're coding for Windows, use my custom keyboard library instead.
-
That's why I call it _HITKEY. BASICally, INKEY$ rules!!!!
Pete
-
That's why I call it _HITKEY. BASICally, INKEY$ rules!!!!
Pete
INKEY$ is just as bad. Try the following, for example:
Now hit I, CTRL-I, TAB, and CTRL-TAB. What's the output that you're seeing?
73 (or 105, depending on caps lock or shift state)
9
9
(nothing)
Ctrl-I is the exact same as TAB -- regardless of capslock, or shift-status, and CTRL-TAB doesn't even exist at all. It's absolutely impossible to generate a ctrl-tab keypress, or to designate the difference between SHFT-CTRL-I, CTRL-I, and TAB.
INKEY$ and _KEYHIT both fail to read multiple keypresses and combinations. Fellippe's solution is only viable in this one singular instance. Try to do the same with CTRL-M with INKEY$.... (Hint: It's the 13th letter of the alphabet, so much like J is 10, M is going to be.... ???) (Hint 2: What's the value of the ENTER key?)
When you start looking at extended key presses, or reading all the various key combinations you can make with your keyboard, you're going to have to make your own input handler. QB64's built in commands aren't up to the task.
-
QB has always had these "Mickey Mouse" challenges. Ctrl + Tab is certainly one of them, as INKEY$ On KEY, etc. are blocked from detecting this combination. INP(&h60) is the Mickey Mouse workaround, but it isn't perfect, as the status doesn't change until either both keys are released, or ctrl is held while a different key is pressed, before tab is pressed again. Also, you have to press ctrl first or write a more elaborate key handling routine....
Pete
-
If you're coding for Windows, use my custom keyboard library instead.
...
Fellippe's solution is only viable in this one singular instance.
Same same.
Until there is a single, universal solution to this, I see nobody having the cake and eating it too.
(i think qb64 programs should target every platform supported by the compiler. i can't really invest in windows-only anything.)
-
QB has always had these "Mickey Mouse" challenges. Ctrl + Tab is certainly one of them, as INKEY$ On KEY, etc. are blocked from detecting this combination. INP(&h60) is the Mickey Mouse workaround, but it isn't perfect, as the status doesn't change until either both keys are released, or ctrl is held while a different key is pressed, before tab is pressed again. Also, you have to press ctrl first or write a more elaborate key handling routine....
Pete
@Pete -- Doesn't work. Run it and hit CTRL-TAB, and then hit CTRL-I. You have the exact same issue here that INKEY$ has. You can't tell the difference in those two keypresses at all.
-
I was wondering, Is there a way to tap into glut's keyboard function to get keypresses? Would there be any difference in doing that? I was looking at the glut functions and can get glutGet and glutDeviceGet to work, but that's all I have experience with so far. How much of glut functions can we access from QB64 code? (Im a newbie in that stuff...)
- Dav