Skip to content

Harden clipboard writes against "clipboard in use" failures#649

Merged
Hirogen merged 7 commits into
Developmentfrom
clipboard-hardening
Jul 9, 2026
Merged

Harden clipboard writes against "clipboard in use" failures#649
Hirogen merged 7 commits into
Developmentfrom
clipboard-hardening

Conversation

@Hirogen

@Hirogen Hirogen commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

Problem

Windows clipboard access throws ExternalException ("Requested Clipboard operation did not succeed") when another application holds the clipboard open — clipboard managers, RDP, Office, launcher tools — even after the WinForms-internal retries (10 × 100 ms). Every clipboard write in LogExpert was unguarded, so a busy clipboard crashed straight into the exception dialog. Previously reported in #195, where the reporter traced it to a clipboard-monitoring launcher app; the code was never hardened.

Changes

  • New ClipboardHelper (LogExpert.UI.Extensions) with TrySetText / TrySetDataObject — catches ExternalException and reports failure via return value instead of crashing. TrySetDataObject uses copy: true so copied data survives app exit (previously inconsistent with SetText).
  • All six call sites routed through it, each with failure feedback fitting its context:
    • LogWindow edit-mode copy + both CopyMarkedLinesToClipboard paths → status-line error
    • LogTabWindow copy-path-to-clipboard → warning message box
    • PluginHashDialog → keeps its success/error message boxes, drops its local try/catch
    • ExceptionWindow → fails silently so the error dialog can never cascade into another error
  • Fixed the verbatim @"\n\n" literal in ExceptionWindow — error reports showed a literal \n\n instead of blank lines, both in the dialog and in copied text.
  • New localized message LogExpert_Common_UI_Message_ClipboardInUse (en/de/zh-CN).

Tests

Four new tests (TDD, red→green) exercise the helper against the real clipboard:
success paths verify the text lands on the clipboard; failure paths hold the Win32 clipboard open from a background thread via Vanara.PInvoke.User32.OpenClipboard — reproducing exactly what an external clipboard tool causes — and assert the helper
returns false instead of throwing. Full suite: 848 passed, 0 failed.

BRUNER Patrick and others added 4 commits July 9, 2026 09:50
Windows clipboard access throws ExternalException when another
application (clipboard manager, RDP, Office, ...) holds the clipboard
open - even after the WinForms-internal retries. Copying in edit mode,
copying marked lines, copying the tab path, and the copy buttons in
ExceptionWindow/PluginHashDialog all crashed into the exception dialog
(previously reported in #195).

All clipboard writes now go through ClipboardHelper.TrySetText /
TrySetDataObject, which report failure instead of throwing. LogWindow
shows the failure in the status line, LogTabWindow/PluginHashDialog
show a message box, and ExceptionWindow fails silently so the error
dialog can never cascade.

Also fixes the literal \n\n (verbatim string) in ExceptionWindow and
uses copy: true for SetDataObject so copied lines survive app exit,
matching SetText.
Use the Vanara.PInvoke.User32 package instead of manual DllImports in
the clipboard lock test fixture, drop the redundant error logging in
ClipboardHelper (every call site already surfaces the failure), and
simplify the PluginHashDialog copy handler to a ternary.
Comment thread src/LogExpert.UI/Dialogs/LogTabWindow/LogTabWindow.cs Fixed
Comment thread src/LogExpert.Tests/Extensions/ClipboardHelperTests.cs Dismissed
Comment thread src/LogExpert.Tests/Extensions/ClipboardHelperTests.cs Dismissed
@Hirogen
Hirogen merged commit 21c4a8e into Development Jul 9, 2026
1 check passed
@Hirogen
Hirogen deleted the clipboard-hardening branch July 9, 2026 10:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant