Platform: Windows 10 21H2 x64. Version: latest as of today Keyboard layout: English (United Kingdom) Problem: shift key and/or space bar does not work at all, therefore I am unable to complete the intro tutorials and can’t even begin to use the program.
I’m happy to provide whatever technical information you need but please don’t ask for a screengrab or video of the problem because it’s exactly as I described: Shapr3D is the active, focused window. I’m able to rotate the camera, interact with surfaces, type in numeric dimensions etc. but space bar does not focus on a face, and shift does not allow multi-select. I’m therefore stuck on tutorial 7.
Some more info about this after being asked in my other thread:
As far as I know there’s nothing special about my environment apart from the lack of Windows Store. I’m not running any third-party AV software or accessibility software which might interfere with keyboard input.
I do use AutoHotKey but none of my AHK scripts capture the space bar or shift key. (I also tried disabling them completely and the problem persists.)
I found a few other people having the same problem or other input-related issues:
I’m also running Corsair iCUE but I closed that completely and still nothing. (Keyboard is a Corsair K95.)
Is there a way of debugging or logging raw keyboard input to Shapr3D so you can see if my keystrokes are even making it into the application? (Although like I mentioned I’m able to type in numbers.)
I assume my English (UK) keyboard layout shouldn’t make a difference?
Something like a UWP-based equivalent of Switch Hitter would be ideal.
Speaking of, here’s a screenshot showing the raw key codes sent when I press space and left shift. Might be worth checking if yours match up.
We are still not sure what might be causing this issue in your setup.
We tested AHK with some sample scripts and in our setup it seem to work without any issue.
The UK keyboard layout on it’s own must not be an issue, many of our users (and also our software engineers) use it.
We don’t have any key logging functionality that you could use for debugging
Can you try the default on-screen keyboard that is shipped with windows by default. Space will not work, because it requires mouse to be hovered, but shift should function and allow you to pan instead of rotate.
Still nothing with the on-screen keyboard, I’m afraid.
Anything else I can try? Happy to use any debugging software or whatever you need to find the root cause. There must be something since at least a couple other people have reported this issue. We can even do a screen share if that would help.
We do have a “Tutorial Mode” under “Settings”. You can access it through these steps:
Turning on “Display keyboard presses” should enable a small helper popover on the right side of the application window, that displays the recognised key presses and their respective key codes if they don’t translate to any ASCII character (or commonly used modifier key).
I don’t think I’m able to access the settings menu without first completing the intro tutorial, right? And I can’t complete the intro tutorial because of the bug
OK, I was able to skip the intro by editing the Shapr3D settings file and changing all the onboarding flags.
(For anyone else looking to do this, the file is located at %LOCALAPPDATA%\Packages\Shapr3D.Shapr3D_dvv5p1vgwv6mp\Settings\settings.dat and can be loaded into the registry editor (regedit) via File → Load/Unload Hive.)
I enabled “Display keyboard presses” but nothing appears, and none of the keyboard shortcuts work (e.g. S for scale; E for extrude). Only numeric input works when I type in dimensions for a shape.
So the main window doesn’t seem to be capturing keyboard input at all; or if it is, it’s not doing anything with it. Only when focusing in an input field (?) do I see any keystrokes.
The keyboard works properly across the app (except in the editor). For example, Shift/Space functions during login, in the items menu, and while using the history sidebar.
However, it doesn’t seem to support Shift and Space for 3D navigation.
Do other shortcuts work in the editor? For example:
Ctrl+1, Ctrl+2, etc., for changing views
Ctrl+U for union, Ctrl+Z for undo
If you bind Shift+X to a command in settings, does it work?
Can you please check your Mouse settings in your OS settings?
The interesting option is “Scroll inactive windows”.
Previously we had issues with Shapr3D misbehaving regards peripheral devices (although it was mouse/scrolling input not being picked up), when this option was turned off. Let me know if this makes a change in your app’s behaviour, but your issues disappearing by something being in focus seem suspicious.
@Akos_Shapr3D The keyboard only functions when I click into a text box to input numeric dimensions, for example to specify the length of a line. In all other areas the keyboard does not work. This includes all the shortcuts you mentioned, none of which work.
Login is done outside the app in my web browser which the app launches when I click sign in.
If I open the hotkey settings panel I am unable to define new hotkeys. Likewise in the history sidebar I’m unable to interact with anything using the keyboard, including being unable to rename layers.
So basically the only place I can use the keyboard is for numeric input within the sketch fields. And even then I am only able to enter a limited set of characters:
@Kristof_Shapr3DScroll inactive windows was turned on. I turned it off and tried again but no change whether it’s on or off.
If you’d be willing I would be happy to have a screen share session on Zoom or whatever so you can see the behaviour yourselves? Or I can probably record a video which shows my keyboard presses on-screen and send you that.
Unfortunately, we can’t unblock the issue you’re experiencing. It seems specific to your setup, involving software like AutoHotKey and CORSAIR iCUE. These tools modify core system behaviour, even when turned off, which likely causes the conflict. All other reported issues were different from yours.
We can’t replicate your setup, and even if we could, it’s unlikely we could fix the issue. The root cause seems to be related to how Windows works with these third-party tools (and might disrupt UWP applications specifically).
Based on your reports, our software isn’t receiving the expected keyboard inputs, as they’re being intercepted by another process. (There are multiple reports on AutoHotKey forums about UWP software being incompatible with AHK).
Additionally, CORSAIR iCUE also has an official page listing programs it conflicts with:
Why does iCUE conflict with other programs?
Unfortunately, creating a piece of software that can do so much requires it to access a lot of different areas within your PC. The same goes for a lot of other software, and when multiple programs are fighting over the same things, issues can occur.
…
The best way to avoid these issues is to keep the number of problematic programs installed to a minimum. If it’s been a while since you’ve tidied up your system, there’s a strong chance that there are at least a few programs that you no longer need or might not have ever been aware of. This would be a perfect time to uninstall these.
We are not sure what is causing it, it could be iCUE, AutoHotKey or something else. The best way to identify the cause of the conflict would be to start with a fresh OS installation, confirm that Shapr3D works, and then gradually reinstall other software while monitoring for issues. Shapr3D should run on a standard Windows setup without interruption.
Thank you @Akos_Shapr3D and @Kristof_Shapr3D for your help and persistence in trying to figure this out. I appreciate it’s an unusual and tricky problem to solve when you don’t have access to the affected environment.
I did try completely disable iCUE (including its background service) and the problem still happened, but while I was looking at services I wondered if some any of the input-related services might be stopped on my machine.
One service called the Touch Keyboard and Handwriting Panel Service was set to manual startup and was not running. Although I don’t use any touch input devices on my machine, I tried starting it anyway (sc start TabletInputService).
Sure enough the problem was solved and my keyboard input is now recognised in Shapr3D.
I assume because the app is cross-platform it relies on this service to process input in some way? Or maybe all UWP apps do?
Either way, starting the service has resolved the problem.
Wow Paul, this is huge. I’m not sure we could have figured this out without your solution. I’m glad everything is working for you now.
This seems to be related to how the Windows UWP framework and WinRT APIs were originally designed, and has nothing to do with our app being cross-platform. Our application is fully native and only uses Windows APIs. That said, this connection was unexpected for us as well.
WinRT: this is a set of modern, object-oriented APIs for building Windows applications. They are designed to be language-agnostic (e.g. they can be consumed by any language that supports WinRT projections, such as C++, C#, JavaScript, Rust), and provide access to a wide range of functionalities and Windows capabilities, including touch input, sensors, and interacting with the Microsoft Store. The UWP platform is built on top of WinRT APIs (in fact, the name “UWP API” is often used informally to mean “WinRT API”). Note that WinRT APIs are not exclusive to UWP apps, and generally they can be used by any application type. All UWP types mentioned before, such as CoreApplication, as well as all UWP XAML types, are actually WinRT APIs. Windows App SDK itself is also a WinRT component, and almost all APIs it exposes are using the WinRT contract.
I’m not a Windows developer (I’m a Linux-based web developer) but it’s hard to imagine why the dependency on that service for keyboard input exists.
Do you use a framework or middleware or anything which might funnel all input through a library which requires the TabletInputService to process input?
Might be worth adding a quick check on startup to see if the service is disabled and warning the user if not?
We don’t use any additional framework inside our app.
A similar issue has been reported and discussed regarding the official Terminal app, with Microsoft also unable to identify or resolve the root cause:
We’ve had approximately 500 users report that their keyboards don’t work in Terminal, and in 98% of those cases it ended up being because they had this service disabled.
The service has been renamed in Windows 11 to “Text Input Management Service”, because it is doing a lot more than it’s originally name has suggested.
We are not pursuing this issue further due to the low number of users affected. Issuing a warning could create problems for users who have this service turned off but are not experiencing any problems. The original issue I posted above was an example of such a case. We’ll though expand our help center article.
Just as a personal add in to remove possibilites. I use corsair Icue i have many custom profiles set up for macros. It does not matter which profile im on for the macros. Shapr3d works completely fine. I think your issue is in AHK
