Make the Ctrl+C copy reliable, and say why it failed when it does

[sethdtwigg]

Selecting a reference in Notepad++ and pressing the hotkey logged Clipboard: No text found after copy operation and inserted nothing.

The real problem: one message, three causes

That single message was produced by three completely different failures, all of which returned an empty string:

1. Modifier keys still physically held from the hotkey
2. The clipboard could not be opened
3. Nothing was actually selected

All three are now fixed, and — more importantly — are now told apart in the log.

1. Held modifiers (most likely cause here)

The copy is synthesised a fraction of a second after the hotkey fires, and nobody releases Ctrl+Alt+L that fast. A physically held Alt combines with the synthetic keystroke, so the target application receives Ctrl+Alt+C instead of Ctrl+C and copies nothing — indistinguishable from "no text was selected".

The timestamps in the report support this: Hotkey pressed! at 14:01:05.759, selection read at 14:01:06.321 — Ctrl+C went out roughly 100–200 ms after the hotkey.

SendKeys now releases any held Alt, Shift or Win before synthesising anything.

2. Clipboard contention

OpenClipboard was called once, and on failure returned an empty string indistinguishable from an empty clipboard. Clipboard managers, editors and browsers all hold the clipboard in short bursts, so this fails often enough to matter. It now retries for up to 500 ms, and reads report why they came back empty.

3. Guessing at a delay

A fixed Sleep(300) was both too short for slow applications and wasted time for fast ones, and told us nothing. The clipboard sequence number is now sampled before the copy and polled for up to 1.5 s. If it never changes, nothing was copied — and the log says exactly that rather than blaming the read:

Clipboard: Ctrl+C did not change the clipboard after 1500ms - was any text selected?

Log noise

Two expected fallback conditions were logged as ERROR on every successful run — Notepad++ is Scintilla-based and exposes no UIA TextPattern, so both fire every time:

ERROR: UI Automation: No text selection found
ERROR: Target window is not an edit control (class: Notepad++)

Both are now ordinary log lines. They also set m_last_error, which buried real failures.

Honest status

I could not reproduce the failure interactively to prove which of the three it was — GUI automation of "hold Alt while another app has focus" was unreliable in my environment, and I'm not going to claim a diagnosis I didn't verify. What I've done instead is make all three causes non-failures where possible, and unambiguous in the log where not. If it recurs, the log will now name the cause outright.

Harness 1053 checks and self-test 242 checks still pass. Version bumped to 1.1.1.