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

lufriem commented 3 months ago

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.

[X] 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:

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

robertosfield commented 3 months ago

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 commented 3 months ago

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:

https://github.com/vsg-dev/vsgExamples/commit/278c6a3a2c18121a07174247fbe605df5faa14eb

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 commented 3 months ago

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:

Pressing Pause/Break doesn't result in any key being reported by vsginput
Pressing NumLock doesn't result in any key being reported by vsginput
Pressing Fn doesn't result in any key being reported by vsginput
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 commented 3 months ago

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:

Pressing Pause/Break doesn't result in any key being reported by vsginput

Pressing NumLock doesn't result in any key being reported by vsginput

Pressing Fn doesn't result in any key being reported by vsginput

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 https://github.com/vsg-dev/VulkanSceneGraph/pull/1248#issuecomment-2255757065, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAPOEQ2OT3QAIH6LLUOLJ6LZOYWCVAVCNFSM6AAAAABLQSOQ4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJVG42TOMBWGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

vsg-dev / VulkanSceneGraph