Comments 12
Особенно доставляют эти up и down в отношении клавиш и их состояния — не сразу поймешь, что
(тут еще бы понять, почему где-то 'F', а где-то 'f', хотя клавиша та же)
— так вот это читается не как «отжатие клавиши, ввод буквы, и нажатие клавиши», а как раз наоборот, «нажатие — ввод буквы — отжатие» (притом что ввод буквы — это уже реакция на нажатие).
F up
Type 'f'
F down
(тут еще бы понять, почему где-то 'F', а где-то 'f', хотя клавиша та же)
Да, именно так
— так вот это читается не как «отжатие клавиши, ввод буквы, и нажатие клавиши», а как раз наоборот, «нажатие — ввод буквы — отжатие» (притом что ввод буквы — это уже реакция на нажатие).
Да, всё именно так. Как и в любом логгере, более новые записи отображаются выше (видно по timestamp на картинке)
'F' — значение из enum, а 'f' — тот символ, который был реально напечатан с учётом клавиатуры и текущей раскладки
'F' — значение из enum, а 'f' — тот символ, который был реально напечатан с учётом клавиатуры и текущей раскладки
Поясню чуть подробнее. На события keyUp и keyDown у нас не приходит введённый символ. Приходит только информация о нажатой клавише. А реальный текст мы можем узнать только на событии keyPress
Что-то смутно мне подсказывает что все это Windows и так за вас делает — и вам надо просто логировать и более высокоуровневые сообщения (а низкоуровневые прятать/сворачивать).
И вообще в общем случае ввод может прийти и не с традиционных девайсов (с речевого ввода например) и там вообще может не быть keyDown/keyUp...
При работе с нетрадиционными девайсами можно заполнить бердкрамбсы вручную. Автоматический режим написан для наиболее часто используемых сценариев.
Ну например, в MSDN написано:
Double-clicking the left mouse button actually generates a sequence of four messages: WM_LBUTTONDOWN, WM_LBUTTONUP, WM_LBUTTONDBLCLK, and WM_LBUTTONUP.
То есть из Windows приходят не только "сырые" сообщения о нажатии/отжатии кнопки, но и уже обработанные — двойной клик произошел. И это истинные сообщения (учитывающие, например, скорость двойного клика в настройках мыши).
Так какой смысл игнорировать эти сообщения, и пытаться потом их восстановить задним числом?
Так мы и не игнорируем.
Если посмотреть на скриншот — https://hsto.org/webt/u4/wh/2l/u4wh2l7n7baleb9kkdtxnwotnpk.png, в сырых данных мы и собираем нативный doubleClick.
Но он прилетает не один, а в последовательности — down/up/doubleClick/up.
Вот из этой последовательности в финальном отображении мы и оставляем только doubleClick по результатам коллапса.
Если посмотреть на скриншот — https://hsto.org/webt/u4/wh/2l/u4wh2l7n7baleb9kkdtxnwotnpk.png, в сырых данных мы и собираем нативный doubleClick.
Но он прилетает не один, а в последовательности — down/up/doubleClick/up.
Вот из этой последовательности в финальном отображении мы и оставляем только doubleClick по результатам коллапса.
Спасибо кэп, см. первую картинку в статье. В случае двойного клика восстанавливать ничего и не надо, напротив, стОит убрать/свернуть «лишние» сообщения, предшествующие (и следующие за) WM_LBUTTONDBLCLK. Выкинуть их «превентивно» нельзя, ибо в таком случае не отловишь одиночный клик. А еще, сюрприз, сообщения WM_LBUTTONSINGLECLICK в винде не существует, и таки придётся анализировать соответствующие пары Down/Up. Аналогичная ситуация и с KeyDown, KeyPress, KeyUp.
Может возникнуть соблазн сделать обработку не на сервере, а на клиентах, типа ближе к телу, сразу учесть особенности платформы и т.п. Но есть один ньюанс) Выпущенную версию клиента обратно не воротишь, улучшить что-то или поправить косяк получится только в следующей версии клиента. Пока будешь делать новую версию, «плохой» клиент успеет распространиться в природе, и попробуй теперь замени его на более новый, стильный, модный и молодёжный. А логика обработки и показа на сервере может быть быстро/легко исправлена и расширена, полностью независимо от клиентов и их версий.
Может возникнуть соблазн сделать обработку не на сервере, а на клиентах, типа ближе к телу, сразу учесть особенности платформы и т.п. Но есть один ньюанс) Выпущенную версию клиента обратно не воротишь, улучшить что-то или поправить косяк получится только в следующей версии клиента. Пока будешь делать новую версию, «плохой» клиент успеет распространиться в природе, и попробуй теперь замени его на более новый, стильный, модный и молодёжный. А логика обработки и показа на сервере может быть быстро/легко исправлена и расширена, полностью независимо от клиентов и их версий.
Объем передаваемых данных?
Кольцевой буфер, по дефолту на 1000 элементов, размер настраивается в коде/конфиге. Размер элемента переменный (json), в ориентировочно десятки-сотни байт. Если всё это вместе превышает ~3Mb, отправляются самые свежие по времени данные, поместившиеся в 3Mb.
Я имел в виду, что объем передаваемых данных можно существенно уменьшить, если делать оптимизацию на клиенте.
Можно. Но, потеряем тогда оригинал, а он бывает важен. Может оно и специфика, но во всех больших контролах, что лично мне пришлось разрабатывать (RichEdit, Spreadsheet, Scheduler), обработка клавиатуры и мышки полностью кастомная. И при любых подозрениях на эту часть кода, я бы обязательно взглянул на неоптимизированный оригинал. Плюс, см. аргументы выше.
Sign up to leave a comment.
Упрощаем лог действий пользователя