Извините, это немного долго. Я хочу быть уверенным, что полностью описываю очень странное поведение, которое я вижу, и то, что я уже пробовал.
Я пишу программу python pygame, которая принимает события клавиатуры. Я пытаюсь взять числовые данные с клавиатуры, а также с обычных чисел на клавиатуре (наряду с другими вводами). Однако состояние клавиши num lock, сообщаемое pygame, вызывает проблему, поскольку оно не согласуется с фактическим состоянием клавиатуры клавиши блокировки.
Основы этого довольно просты, у меня есть событие l oop
while True:
for event in pygame.event.get():
и не имеют проблем с получением событий KEYDOWN и проверкой модификаторов для применения из растрового изображения event.mod, и все это прекрасно работает. Однако я обнаружил нечто неожиданное. Чтобы быть уверенным, что пользователь намеревается нажать, скажем, клавишу 4 на клавиатуре, а не стрелку влево, программе необходимо проверить состояние клавиши-модификатора num lock (флаги event.mod, которые идут вместе с ключом event.key в Ключевое событие). Опять же, это просто, но есть неожиданная проблема с ключами блокировки (num lock и caps lock), которые имеют состояние и остаются включенными или выключенными.
Проблема заключается в том, что при запуске программы она не учитывает текущее состояние системы с ключом num lock (при изучении этого я обнаружил то же поведение с ключом caps lock). Независимо от того, включены ли клавиши caps lock или num lock (а светодиодные индикаторы горят), при запуске программы pygame это означает, что клавиши находятся в выключенном состоянии. Я подтвердил это, используя состояние event.mod и прочитав его напрямую с помощью pygame.key.get_mods () . Я вижу состояние индикатора на клавише и могу сказать, включен ли он. Независимо от того, запускаю ли я игру с выключенной блокировкой или включенной, она всегда сообщает, что мод выключен. Если при запуске игры загорается светодиод, игра сообщает о том, что он выключен, и если я затем нажимаю клавишу блокировки (выключая светодиод), игра начинает показывать установленный мод!
Даже усложнять его Более того, если вы выйдете из игрового окна, а затем измените состояние ключа блокировки и затем вернетесь go, pygame не распознает, что состояние изменилось, и все равно отправит те же флаги event.mod, что и раньше.
Похоже, что pygame на самом деле не отслеживает состояние системы клавиш блокировки, но предполагает, что они выключены при запуске программы, и воспринимает изменения клавиш только в том случае, если они переключаются, когда игра имеет фокус.
Как уже упоминалось, я попытался pygame.key.get_mods () , но он сообщает о том же противоречивом состоянии, что и флаги event.mod. Я также попытался pygame.key.set_mods () , но это просто меняет игровое представление о состоянии и не влияет и не обеспечивает способ соответствия базовому состоянию системы клавиш блокировки (светодиоды не не изменяет состояние и не влияет на то, что другие приложения считают состоянием, а именно на то, что думает pygame.) состояние системы клавиш caps lock и num lock.
Это делает пользователя совершенно запутанным, они видят, что индикатор caps lock или num lock горит (или нет), и все же игра ведет себя непоследовательно с этими состояниями.
Кто-нибудь еще видел эту проблему? Вы нашли способ ее решить?
Это некорректное поведение при запуске можно очень просто воспроизвести, запустив его с включенной клавишей caps lock, а затем снова с заблокированной заглавной буквы:
#!/usr/bin/env python
import pygame
pygame.init()
pygame.display.set_mode((400, 400))
print(pygame.key.get_mods())
Я получаю 0, напечатанный при запуске с включенной или выключенной блокировкой заглавных букв, указывая, что это не получает правильное состояние блокировки при запуске программы.