如何将RawInput RAWKEYBOARD结构转换为DirectInput DIK_常数？

Question

我正在将当前使用DirectInput的应用程序转换为使用RawInput。(DirectInput在很大程度上是一个不受欢迎的API。)

不幸的是，尽管RawInput是DirectInput的推荐接班人，但它似乎没有以与DirectInput完全相同的方式提供键盘数据。

DirectInput使用DIK_*常量(如DIK_A、DIK_RETURN等)若要在键盘上定义特定物理键，请执行以下操作。这些键在键盘硬件上是一致的，但不因键盘布局而改变。(例如，DIK_Q指的是Q键在标准的英美QWERTY键盘上的物理位置上的任何键。)在我的例子中，这是想要的行为。

RawInput的RAWKEYBOARD结构提供了一个MakeCode和一个VKey。我不能使用VKey，因为这取决于键盘布局。

但是MakeCode与DIK_*常量并不对应1:1。特别是，它没有区分左键和右键，ctrl键和alt键，或者大多数数字垫键与它们的其他键。

因此，我的问题是:是否可以使用RAWKEYBOARD结构的内容来计算等效的DIK_*常量？假设MakeCode是解决这个问题的一部分，我是否可以依赖于MakeCode在键盘硬件上是常量，就像DIK_*常量一样？

Answer 1

我并不是100%确信这在所有键盘硬件中都是可靠的，但我似乎可以使用MakeCode和Flags (特别是RI_KEY_E0和RI_KEY_E1标志)字段来确定按下或释放的实际物理键，并将其映射到DIK_常量。我使用这张桌子来确定单个键的大部分make/scan代码，然后尝试找出其余密钥的扫描/生成代码和标志。

我在四个不同的键盘上测试了这一点，所有这些都产生了相同的制造代码/标志:两个USB键盘，一个PS/2键盘，以及在一个运行bootcamp的Macbook上内置的键盘。

我希望有一些文档来确认，我可以依靠make代码和标志在所有键盘上保持一致，但到目前为止，这似乎还不错。

更新：现在已经5年了，我的软件已经有了成千上万的真实用户，而我还没有收到一份关于不正确的密钥映射的报告。在这一点上，我有99.999%的信心，这种方法始终在所有的键盘上工作，但我不能确定事情不会改变在未来。