Search Issue Tracker
Won't Fix
Votes
1
Found in
2020.3.37f1
2021.3.6f1
2022.1.10f1
2022.2.0b2
2023.1.0a4
Issue ID
UUM-9669
Regression
No
New InputSystem does not register keyboard presses when build is embedded in Forms Window
Reproduction steps:
- Open the user’s attached project “SlimEmbeddedUnityInputSystemTest”
- Build the project
- Download “EmbeddedUnityInputSystemTest.zip” and extract it
- Go to \\IN-6354_EmbeddedUnityInputSystemTest\\UnityEmbeddedInWindowsForms\\UnityEmbeddedInWindowsForms\\UnityBuild
- Delete the “UnityBuild” folder’s contents and place built Player files
- Open \\IN-6354_EmbeddedUnityInputSystemTest\\UnityEmbeddedInWindowsForms\\UnityEmbeddedInWindowsForms.sln"
- Press “Start”
- Click the "Start and embed” button in the Windows form
- Wait for the Player to load and press random keyboard buttons
Expected result: Both new and old Input System receive the same keyboard input
Actual result: New Input System doesn’t receive the keyboard input
Reproducible with: 2020.3.37f1, 2021.3.6f1, 2022.1.10f1, 2022.2.0b2, 2023.1.0a4
Reproducible on: Windows 10
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Unity CIL Linker fails on Player build when persistent listeners have "<" and ">" in their XML attribute names
- ”Lighting data asset ‘LightingData’ is incompatible with the current Unity version…” warnings are thrown when saving Indoors (URP) and Outdoors (URP) Scenes as Scene Templates
- [iOS] The screen blinks when transitioning from custom to Unity splash screen
- [macOS] ”Ignoring depth surface load action as it is memoryless” warnings are thrown when taking Game View Snapshot
- UI Builder Inspector scrolls back up when changes on an expanded but not fully displayed Inspector tab are saved
Resolution Note:
Unfortunately, this happens due to combination of two things:
1. The new input system uses raw input API to receive keyboard input instead of the legacy keyboard messages;
2. The limitation in Windows that makes raw input to only get sent to parent Windows.
Since Unity runs in a separate process, it is not able to see those events and therefore it looks like it's not registering them. This has been discovered by several customers, and there has been a discussion on forums regarding this issue: https://forum.unity.com/threads/keyboard-input-is-not-registered-when-unity-is-embedded-in-a-wpf-application.962928/
That forum thread also contains a workaround that you can do to forward the keyboard events from your parent application to Unity.