+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: _KEYHIT Riddle me this??? (/showthread.php?tid=2948)
_KEYHIT Riddle me this??? - Pete - 08-15-2024
Here is a modified version of the _KEYHIT Wiki example...
Code: (Select All)
DefLng A-Z
Screen _NewImage(800, 600, 8)
Cls , 1
font = _LoadFont("cyberbit.ttf", 24)
unifont = _LoadFont("cyberbit.ttf", 24, "UNICODE")
_Font font
Do
x = _KeyHit
If x And x <> oldx Then
Select Case x
Case Is > 0
Color 10
Print "Pressed "; 'positive value means key pressed
oldx = x
Case Else 'negative value means key released
Color 2
Print "Released ";
x = -x
oldx = 0
End Select
Select Case x
Case Is < 256
If x < 256 Then 'ASCII code values
Print "ASCII "; x;
If x >= 32 And x <= 255 Then Print "[" + Chr$(x) + "]" Else Print
End If
Case 256 To 65536 '2 byte key codes
Print "2-BYTE-COMBO "; x And 255; x \ 256;
x2 = x \ 256
If x2 >= 32 And x2 <= 255 Then Print "[" + Chr$(x2) + "]" Else Print
Case 100000 To 199999 'QB64 Virtual Key codes
Print "SDL VK"; x - 100000
Case Else
If x >= 200000 And x < &H40000000 Then
Print "QB64 VK"; x - 200000
_Continue
End If
If x >= &H40000000 Then 'Unicode values (IME Input mode)
Print "UNICODE "; x - &H40000000; "0x" + Hex$(x - &H40000000) + " ...";
cx = Pos(1): cy = CsrLin
_Font unifont
Locate cy, cx
Color 15
z$ = MKL$(x - &H40000000) + MKL$(0)
Print z$ + z$ + z$;
_Font font
Locate cy, 1: Print
End If
End Select
End If
LoopDo this...
PRESS ALT.
RELEASE ALT.
So why does it record just the SDK value when alt is pressed, but records both the SDK and ASCII values when released? I'd feel better about the operation if it did not cycle back to deliver the -18 ASCII value after previously delivering the -308 SDK value when the Alt key was released.
Pete
RE: _KEYHIT Riddle me this??? - SMcNeill - 08-16-2024
The problem here is GLUT itself. Try a few more various keys -- such as CTRL + any number key... Those won't report at all for you.
Glut is BROKEN when it comes to keyboard handling. We honestly and truly need to yank that BLEEPER out and replace it with *anything* else. The problem with that is... it controls so FLIPPING much of the crap we do. We'd basically end up with the same crappy issues that popped up when Galleon began to swap from SDL to GLUT -- half the commands didn't work and they all needed to be patched up and tweaked to start operating properly once again.
Slowly, I think we're moving away from GLUT dependency with all the new libraries and such to handle things. Hopefully, in the next 5 years (if the world doesn't end by then), we'll be able to fully gank GLUT out and replace it with something proper and all these type of issues will disappear for us.
Until then, all you can do is what I do -- Cuss GLUT!!
(And use my keyhit library as a replacement on Windows.)
RE: _KEYHIT Riddle me this??? - krovit - 08-16-2024
(08-15-2024, 03:40 PM)Pete Wrote: PRESS ALT.Well! If you're asking yourself... what can I say?
RELEASE ALT.
So why does it record just the SDK value when alt is pressed, but records both the SDK and ASCII values when released? I'd feel better about the operation if it did not cycle back to deliver the -18 ASCII value after previously delivering the -308 SDK value when the Alt key was released.
Pete
Anyway, just to contribute something if it helps:
if I press or release the left ALT, I get a line that says 'Pressed/Released SDL VK 308'.
Instead, if I press the right ALT, I get TWO lines that say 'Pressed/Released SDL VK 306 / 307'.
I don't know if what I'm saying means anything to you...
(08-16-2024, 07:43 AM)SMcNeill Wrote: [...] Hopefully, in the next 5 years (if the world doesn't end by then) [...]
I knew there were 'thinking' people in here...
RE: _KEYHIT Riddle me this??? - DSMan195276 - 08-16-2024
I think this is fixed in the latest version, the `-19` is no longer reported. We upgrade FreeGLUT in 3.12.0 and I suspect that fixed it.
That said, the underlying issues with `_KeyHit` are both a GLUT and QB64 problem. _KeyHit is IMO a bad API because it's acts like it supports both text input and individual key state, but those things don't mix. If you look at the kinds of events Windows sends to programs you'll see it clearly separates keyboard physical key press/release events (`WM_KEYUP`, `WM_KEYDOWN`, etc.) from text input events (`WM_CHAR`). `WM_CHAR` does not have a concept of press/release because the value does not directly map to a physical key, think of it like `INKEY$`. `WM_KEYUP` and `WM_KEYDOWN` do report press/release, but they do not report ASCII/text values, so there's no difference between hitting 'a' and 'A' as it's the same physical key.
_KeyHit is basically both of those combined - It's designed to give you the text input capabilities like `INKEY$` but also the press/release events associated with physical keys. It gets messy because the inputted text does not really have press/release events in that fashion.
Unfortunately GLUT made the same mistake as QB64, it's fundamentally broken because its `glutKeyboardUpFunc` callback conflates inputted ASCII values with key release events. These do not map directly to physical keys and thus the release events do not always make sense (try the sequence of "Press shift, press a, release shift, release a").
RE: _KEYHIT Riddle me this??? - TerryRitchie - 08-16-2024
The example program works correctly in version 3.13.1
RE: _KEYHIT Riddle me this??? - Pete - 08-16-2024
Thanks @TerryRitchie
I just installed QB64 Phoenix Pi. It worked correctly on that version, too.
Also responded to your On ERROR question in the other thread.
+2 to DSMan for the full explanation. Steve also mentioned the problems with GLUT and _KEYHIT.
I'm weary of switching from the devil I know (INKEY$) to the devil I don't know (_KEYHIT), but as long as the newer versions have resolved the double release reporting issue, I'm a bit more confident the switch may be possible.
Thanks again guys,
Pete