Excel is open. A person is in the middle of a cell. Your script is supposed to keep keying invoices into a crusty Win32 line-of-business app in the background, then click "Done" in Teams, Slack, or whatever Electron shell the company uses for ticketing.

That should be two quiet steps. With SendInput and libraries in the robotgo family, it becomes one loud one. The cursor jumps. The target window comes to the front. The value that person was about to paste lands in someone else's form.

Vendors call this "foreground automation." Another way to say it: you just mugged the operator.

So you switch to posting window messages. The old Win32 app suddenly behaves. No focus grab, no physical cursor, the operator may not even notice the bot. Then the same calls hit the Electron app and disappear. The window is right there. The click never happened. Games, Raw Input apps, and a lot of modern UI toolkits simply do not eat PostMessage.

That split is the everyday Windows RPA problem: the backend that can stay in the background cannot punch through stubborn windows; the backend that can punch through cannot stay in the background.

winput is built around that crack.

You think in windows, not raw HWNDs and scan codes. Find the invoice app, find the Edit child, Click, Type, press Enter. By default that path uses the message backend. The operator's mouse can stay in Excel. The docs are explicit: the message backend needs no focus and does not move the physical mouse.

Invoices done, now the Electron app. Keep the same calls, just flip the backend first:

if err := winput.SetBackend(winput.BackendHID); err != nil {
    // driver not installed: degrade loudly, don't pretend it worked
}

After that it is still Click, still Type. But nothing is going into the window queue anymore. You are injecting HID through the Interception driver, which is how the library talks to games, anti-cheat-ish input paths, and other windows that shrug at synthetic messages. Electron apps with unreliable HWNDs sit in that same bucket.

Someone will ask: if HID is stronger, why not use it for everything?

Because it isn't free. You have to install the driver. The real cursor moves. The window usually needs to be in the foreground. Run HID all day against that old invoice app and you have given "background" back. Message input is for not bothering people. HID is for windows that refuse to listen. The point of winput is not that one mode is cooler. It's that you don't write two automations for two kinds of windows.

The thing I've been tired of, writing RPA, is not a missing Click helper. It's a single flow that contains two window types, and a library that will only give me one mouth. One side says "we support background" and then only works on Notepad. The other says "we can drive games" and then the operator swears the first time they touch the mouse.

Wiring both to the same Window object sounds plain. That's what infrastructure is supposed to sound like.

It is not a master key. The message backend loses to UIPI, so a higher-privilege window still won't accept your posts. Modifier hotkeys that the target reads with GetKeyState may not look like real chords, and the library will temporarily fall back to foreground key events. HID is Windows-only and tied to Interception. All of that is in the docs. Don't ship as if you didn't read it.

But on the desk that actually shows up in RPA shops (legacy Win32 on one side, an Electron shell on the other, and a human who does not want their mouse stolen), dual backends are not a bonus feature. They're why the library exists.

Other tools make you choose: be quiet, or get through.

This one lets you finish the quiet work quietly, then grow a second set of teeth for whatever's left.