Fixed various issues with handling 'extended' keys on the Windows pla…

[lufriem]

Description

Fixed various issues with handling 'extended' keys on the Windows platform

• the code now distinguishes between 'left' and 'right' ALT and CTRL modifier keys
• the code now handles the 'Applications' key (VK_MENU) correctly
• added the various keys on the numpad (VK_NUMPADx, VK_MULTIPLY, VK_ADD etc)
• 'scroll lock' is now handled
• 'print screen' is now correctly handled (VK_SNAPSHOT instead of VK_PRINT)

Fixes #1198

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

I ran the vsgInput example

Test Configuration:

• SDK: Windows 10, Visual Studio 2022

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[robertosfield]

Why wouldn't this map to KEY_Menu?

[lufriem]

VK_MENU on Windows is the (left) 'Alt' key. KEY_Menu is (according to KeyEvent.h) supposed to be "VK_APPS, the context-menu key" (I elaborated on this a bit more in the issue discussion)

[robertosfield]

If VK_PRINT shouldn't map to KEY_Print would should VK_SNAPSHOT?

What does VK_PRINT and KEY_Print meaning and are you assuming?

As a general reference I used X11 conventions that the OSG adopted decades ago, so whole not 1:1 compatible the VSG KEY_ enum is broadly like the OSG's.

[lufriem]

OK that's a good/valid question..

• I assumed KEY_Print would be the 'Print screen' hotkey/functionality.
• while the MSDN lists the VK_PRINT constant all it says is that it is the 'PRINT key' (I searched around a bit but I could only find this stackoverflow discussion where it's stated that VK_PRINT is basically a nowadays unused remnant from 83/84 key IBM XT/AT machines). However looking at they keyboard in front of me, pressing the 'PrtSc' key I could see that the VK_SNAPSHOT event was created by Windows :)

[robertosfield]

I just tried under Linux and pressing "Press Screen" is mapping to VK_PRINT, so if Windows generates VK_SNAPSHOT for this key then that would be correct mapping.

[robertosfield]

Um... VK_Menu isn't a menu but VK_APPS is?

[lufriem]

Please see this comment above

[robertosfield]

While it's great to see some obvious mapping that should be included originally, some of the changes look very odd and not suitable for merging without further discussion and testing under Windows. FYI, I didn't write the Win32 support in the VSG as use Unices predominantly and Windows only occasionally recently, so for Win32 changes I rely upon the community, and need to follow up with official docs to settle any questions if they remain.

[robertosfield]

To help with testing I've added a map<vsg::KeySymbol, std::string> to the vsginput example that provides the enum entry name when we press/release keys so we can more easily see how the VSG is treating keys:

vsg-dev/vsgExamples@278c6a3

My aim with the vsg::KeyRelease/keyPress events is the vsg::KeySymbol reported will be same across platforms.

I have also merged this PR as a branch for myself and others to test/make amendments before anything final gets merged with VSG master.

https://github.com/vsg-dev/VulkanSceneGraph/tree/appcodegen-WindowsKeyHandling

If possible it would be helpful for users to try out multiple platforms to see whether we are consistently getting the mapping they would expect and where it differs due to bugs we can directly fix them, but if it looks like an inconsistency between platforms then we'll need to figure out what to standardize on.

[robertosfield]

I have booted my Windows machine checked out this branch and tested against the updated vsginput and can confirm that Linux and Windows now behave much more closely thanks to this PR :-)

I have merged this PR but note that there a still a few missing mappings:

1. Pressing Pause/Break doesn't result in any key being reported by vsginput
2. Pressing NumLock doesn't result in any key being reported by vsginput
3. Pressing Fn doesn't result in any key being reported by vsginput
4. Pressing F10 passing vsginput, no idea why this might be.

I have other work to get on with today so I'll leave these as outstanding for now. Others are welcome to jump in a test/fix any issues they see.

[rolandhill]

Hi Robert, I was looking at differences in how Linux and Windows treat the numpad keys last week. I found that pressing numpad numbers in Linux does not produce any output in ImGui::InputText controls (you can test in the ImGui demo window). I made the table below. The first section shows the contents of the 'base', 'modified' & 'modifier' members when you press the NORMAL 3 key. Both Linux and Windows produce the same result. The second section shows the same thing when you press the NUMPAD 3 key. Windows appears to be converting the numpad number into a normal number, except with a different base. Linux produces both KP category base and modified members. I'm not sure which is correct or what the intention is. I do know that Numpad keys don't work in ImGui on Linux (on my machine). *** Keyboard code differences Normal 3 (Both the same) Base, Modified, Modifier Windows: KEY_3, KEY_3, MODKEY_NumLock Linux: KEY_3, KEY_3, MODKEY_NumLock Numpad 3 Base, Modified, Modifier Windows: KEY_NEXT, KEY_3, MODKEY_NumLock Linux: KEY_KP_NEXT, KEY_KP_3, MODKEY_NumLock Regards, Roland

…

On Mon, 29 Jul 2024 at 22:08, Robert Osfield ***@***.***> wrote: I have booted my Windows machine checked out this branch and tested against the updated vsginput and can confirm that Linux and Windows now behave much more closely thanks to this PR :-) I have merged this PR but note that there a still a few missing mappings: 1. Pressing Pause/Break doesn't result in any key being reported by vsginput 2. Pressing NumLock doesn't result in any key being reported by vsginput 3. Pressing Fn doesn't result in any key being reported by vsginput 4. Pressing F10 passing vsginput, no idea why this might be. I have other work to get on with today so I'll leave these as outstanding. — Reply to this email directly, view it on GitHub <#1248 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAPOEQ2OT3QAIH6LLUOLJ6LZOYWCVAVCNFSM6AAAAABLQSOQ4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJVG42TOMBWGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>