-
Notifications
You must be signed in to change notification settings - Fork 927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows is not location aware for modifier keys #3611
Comments
Same goes for all other modifiers (except Alt, which is really Alt and AltGr), in which case I get 4 modifier events:
But if I just press AltGr, I get 2 events immediately before I even release:
|
The thing that you shouldn't use this API unless you really need it is documented on the API. |
I give up! You tell me on a previous issue that I should use the modifiers to detect these keys states. And now you tell me that I shouldn’t use modifiers to detect this. It’s entirely possibly to detect this using the Windows C API. What is the correct way to detect this using won’t on windows? |
I said numerous times that if you want to test for |
I would like to test for if left shift is pressed, held or released and also if right shift is pressed, held or released, and to be able to do this for both at the same time. |
If you want to try and do this in 100% cases in the current state of things there's no clear way to do this cross platform, because keymap queries are not done. I'll work on that for 0.31, but no promise. If you only care when your app was focused, you can manually track them by using the Modifier input is different, because it doesn't directly map to physical key and as was said numerous times, If you want a binding, like Keep in mind that if user focuses your application with shifts latched, and you trigger something based on that, it'll clearly be very surprising for them; most apps require to repress. |
Any example you are able to give would be very appreciated. It seems like it should be obvious but I’m just not getting it, and am getting a bit frustrated as a result. Sorry that I let that impact my communication style. |
Thanks for the explanation. I don’t agree that will work; it’s what I’m currently doing and as I tried to explain in #3610 (comment), it doesn’t capture all the relevant events for this to work. |
It doesn't work because it's marked as #[derive(Default)]
struct InputTracker {
left_shift: bool,
right_shift: bool,
}
let mut tracker = InputTracker::default();
match window_event {
WindowEvent::KeyboardInput {event, .. } {
// We don't really care about repeat, it's still pressed.
if event.logical_key() == NamedKey::Shift {
let location = event.location();
let is_pressed = event.is_pressed();
if location == KeyLocation::Left {
tracker.left_shift = is_pressed;
}
if location == KeyLocation::Right {
tracker.right_shift = is_pressed;
}
}
}
// Doesn't really matter what state it's.
WindowEvent::Focused(_) => {
tracket = Default::default();
}
} Maybe something like that will work for you? |
Thanks for the suggestion. I hadn't clocked that the Using that implementation, I still have the same problem - only one of the release events is emitted and results in one of the keys being marked as pressed when it is released:
|
This is also a bug then, with either For now you can assume on windows that |
Thanks for clarifying. I still don't think that helps because the
If I were to try and visualise that, it would be something like this:
|
@junglie85 no, I mean that you use my suggest and to detect the second release, you use the modifiers event, since it means that both shifts are released, and resetting with it instead of setting is more robust, so it's fine. |
Oh, I see. I was ignoring the repeats but I actually need to account for those because that will continue to tell me that the "other" key is still pressed. I was ignoring those for reasons but I can rework that. Thanks :-) |
@kchibisov Unfortunately that approach does not work, because neither a Here, without applying the suggested modifier state: And here with the suggestion applied: As can be seen, applying the modifier state correctly shows all keys as released. But it does not help with the missing |
Description
Cannot detect when left or right version of a modifier is pressed, it just shows as a single modifier without the left/right info. e.g. if left shift is down, it does not detect that right shift is down. I can also press left shift followed by right shift, then release left shift and it only reports a release when I finally release right shift.
This seems pretty buggy to me.
Windows version
Winit version
0.29.15
The text was updated successfully, but these errors were encountered: