Known Limitations

Known Limitations

KeepPressing synthesizes input through the Windows SendInput API. That comes with inherent limits. None of these are bugs — they're consequences of how Windows input and timing work.

1. It can't drive elevated (admin) windows

Windows UIPI (User Interface Privilege Isolation) blocks a normal-integrity process from sending input to a higher-integrity (elevated) window. The input is silently dropped. Fix: run KeepPressing.exe as administrator when your target runs elevated. See Troubleshooting.

2. No "up" guarantee if the process is force-killed

In normal operation, stopping (or closing the app) always releases a held key/button — the release is part of the stop contract (see Threading & ConfigureAwait). But if you force-kill the process (e.g. taskkill /F, a crash with no chance to run cleanup), a key/button held in Hold mode can stay logically down. Fix: press the physical key/button once to clear it.

3. Keyboard Hold does not emulate auto-repeat

In Hold mode the key's down is sent once and held; KeepPressing does not generate the OS-style repeated character stream you'd get from physically holding a key. This is effective for apps/games that check key state (e.g. GetAsyncKeyState), but won't spam characters into a text field.

4. Repeat rate is approximate

Repeat timing uses PeriodicTimer, whose real rate depends on the OS timer resolution. An interval of 10 ms (≈ 100 presses/sec) is a practical floor; very small intervals won't be exact.

5. Some apps ignore synthetic input

Games that read Raw Input directly, and anti-cheat–protected applications, may ignore or detect synthesized input. KeepPressing sends scancode-based keystrokes to maximize compatibility with normal apps, but it cannot defeat software that specifically rejects injected input.

6. F8 / Esc are reserved during coordinate capture

While you're picking a fixed coordinate, F8 and Esc belong to KeepPressing (to confirm/cancel) and won't reach other apps. This is only during capture, and the UI says so.

7. "Current cursor position" + on-screen Start = clicking this app

If you start with the on-screen Start button while in current cursor position mode, the first presses land on KeepPressing's own window (that's where the cursor is). Fix: start with the hotkey, or use fixed coordinates.

---

Related: Troubleshooting · FAQ