Repository navigation
fix: Num Lock injetado no Windows era descartado - #22
Conversation
O hook reporta NumLock como scancode 0x45 estendido, mas na injeção E0 45 não mapeia para tecla nenhuma (MapVirtualKey devolve 0). NumLock agora sai como 0x45 simples; Pause, que o hook reporta como 0x45 simples, sai por VK_PAUSE para não virar NumLock. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
ℹ️ No critical issues — one test-coverage suggestion inline.
Reviewed changes: the single commit on fix/numlock-windows, covering native/src/lib.rs and CHANGELOG.md.
Injector::sendkey mapping: NumLock (0x45extended) is now injected as a plain0x45scancode. Pause (0x45non-extended) is injected viaVK_PAUSE. Other keys behave as before, andrelease_allgoes through the same mapping.- Regression test:
numlock_sai_sem_flag_estendida_e_pause_por_virtual_keycovers the new mapping. - Changelog:
Unreleased/Fixedentry added.
The mapping logic reads correctly. VK_PAUSE resolves through the existing KeyboardAndMouse::* import. Held-key tracking in InputState still uses the original (scancode, extended) tuple, so releases map consistently. The real Windows to Windows check in the PR checklist is still open, and I could only review the Windows code by reading it.
claude-sonnet-5-5 | 𝕏
| injector.send(Event::Key { scancode: 0x45, extended: true, down: true }).expect("numlock"); | ||
| injector.send(Event::Key { scancode: 0x45, extended: false, down: false }).expect("pause"); | ||
| let sent = SENT.with(|sent| sent.borrow().clone()); | ||
| assert_eq!(sent, [(INPUT_KEYBOARD, 0x45, KEYEVENTF_SCANCODE), (INPUT_KEYBOARD, 0x45, KEYEVENTF_KEYUP)]); |
There was a problem hiding this comment.
The test name says Pause goes out "por virtual key", but record only captures (type, wScan, dwFlags) and drops wVk, and Pause is only sent as a key-up. Reverting the (0x45, false) arm to a plain scancode would still pass. Consider capturing wVk in record (or adding a dedicated assertion) and sending Pause down as well, so VK_PAUSE is actually asserted.
Technical details
# Pause virtual key is not asserted by the test
## Affected sites
- native/src/lib.rs:1226-1237 — `record` stores `(type, wScan, dwFlags)` only, so `wVk` is invisible to tests
- native/src/lib.rs:1244-1246 — Pause is sent only with `down: false`, and the expected tuple `(INPUT_KEYBOARD, 0x45, KEYEVENTF_KEYUP)` is identical to what a plain scancode path would produce
## Required outcome
- The test fails if the `(0x45, false)` arm stops using `VK_PAUSE`.
## Suggested approach (optional)
- Extend the `SENT` tuple (or add a second recorder) with `wVk`, and update the other assertions that destructure it, e.g. `release_all_solta_scancodes_injetados`.
- Send Pause with `down: true` too.
Problema
De Windows para Windows, o Num Lock não funcionava no remoto.
Causa
O hook de teclado reporta NumLock como scancode
0x45comLLKHF_EXTENDED. O injetor repassava comKEYEVENTF_SCANCODE | KEYEVENTF_EXTENDEDKEY, ou sejaE0 45, que não mapeia para nenhuma tecla (MapVirtualKey(0xE045, MAPVK_VSC_TO_VK_EX) = 0, enquanto0x45 → VK_NUMLOCK). Pause chega como0x45simples e seria injetado como NumLock.Correção
Injector::send(native/src/lib.rs): NumLock sai como0x45sem a flag estendida; Pause sai porVK_PAUSE. Vale para qualquer servidor (Windows, mac, Linux), pois todos chegam ao mesmo injetor.Testes
numlock_sai_sem_flag_estendida_e_pause_por_virtual_key🤖 Generated with Claude Code