08-16-2024, 03:08 PM
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").
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").