Table of Contents

Class ClipboardHelper

Namespace
SharpConsoleUI.Helpers
Assembly
SharpConsoleUI.dll

Cross-platform clipboard helper for console applications. On Linux tries wl-clipboard, xclip, xsel. Falls back to an in-process buffer when no external tool is available. Operations are best-effort and will not throw on failure.

public static class ClipboardHelper
Inheritance
ClipboardHelper
Inherited Members

Properties

Backend

The clipboard backend currently in use. Triggers detection on first access.

public static ClipboardBackend Backend { get; }

Property Value

ClipboardBackend

MaxOsc52Bytes

Maximum base64 payload size for OSC 52; larger copies skip OSC 52.

public static int MaxOsc52Bytes { get; set; }

Property Value

int

Osc52Mode

Controls OSC 52 emission on copy. Default Auto.

public static Osc52Mode Osc52Mode { get; set; }

Property Value

Osc52Mode

Methods

GetText()

Returns the current text content of the system clipboard, or empty string on failure.

public static string GetText()

Returns

string

GetTextWithTimeout(int)

Returns the clipboard text without ever blocking the caller for more than timeoutMs milliseconds. The Windows path is the in-process Win32 read (instant), but the Unix backends spawn a child process (xclip -o / wl-paste / pbpaste) that can stall — running that on the UI thread is the same watchdog hazard as the Windows copy was (issue #42). This runs the read on a background thread and, if it does not complete in time, returns the in-process buffer so a paste can never hang the render loop. Use this from UI-thread paste paths; GetText() remains the (possibly blocking) full-fidelity read for non-UI callers/tests.

public static string GetTextWithTimeout(int timeoutMs = 200)

Parameters

timeoutMs int

Returns

string

SetText(string)

Copies the specified text to the system clipboard.

public static void SetText(string text)

Parameters

text string

Remarks

The external-tool backends (clip.exe, pbcopy, xclip, xsel, wl-copy) spawn a process and wait on it. That blocking I/O is dispatched to a background thread so a copy never stalls the UI/render thread — on Windows, spawning clip.exe per copy was slow enough to trip the main-loop "unresponsive" watchdog (issue #42). OSC 52 emission and the in-process fallback are cheap and stay synchronous, so callers and tests observe them immediately.