Ошибка CLIPBRD_E_CANT_OPEN при установке буфера обмена из .NET

На самом деле, я думаю, это ошибка Win32 API.

Чтобы установить данные в буфер обмена, вы должны сначала Открой это. Буфер обмена может быть открыт только для одного процесса. Итак, когда вы проверяете, имеет ли другой процесс открытый буфер обмена по любой причине, ваша попытка открыть его потерпит неудачу.

Так уж получилось, что службы терминалов отслеживают буфер обмена, и в более старых версиях Windows (до Vista) вам нужно открыть буфер обмена, чтобы увидеть, что внутри ... что в конечном итоге блокирует вас. Единственное решение - дождаться, пока службы терминалов закроют буфер обмена, и повторить попытку.

Однако важно понимать, что это не относится к службам терминалов: это может случиться с чем угодно. Работа с буфером обмена в Win32 - это состояние гигантской гонки. Но, поскольку по замыслу вы должны возиться с буфером обмена только в ответ на ввод данных пользователем, это обычно не представляет проблемы.

Это вызвано ошибкой / функцией в буфере обмена служб терминалов (и, возможно, другими вещами) и реализацией буфера обмена .NET. Задержка открытия буфера обмена вызывает ошибку, которая обычно проходит в течение нескольких миллисекунд.

Решение состоит в том, чтобы попробовать несколько раз в цикле и засыпать между ними.

for (int i = 0; i < 10; i++)
{
    try
    {
        Clipboard.SetText(str);
        return;
    }
    catch { }
    System.Threading.Thread.Sleep(10);
} 

На самом деле может возникнуть другая проблема. Вызов фреймворка (варианты WPF и winform) примерно так (код взят из отражателя):

private static void SetDataInternal(string format, object data)
{
    bool flag;
    if (IsDataFormatAutoConvert(format))
    {
        flag = true;
    }
    else
    {
        flag = false;
    }
    IDataObject obj2 = new DataObject();
    obj2.SetData(format, data, flag);
    SetDataObject(obj2, true);
}

Обратите внимание, что в этом случае SetDataObject всегда вызывается со значением true.

Внутренне это вызывает два вызова win32 api: один для установки данных, а другой для их удаления из вашего приложения, чтобы он был доступен после закрытия приложения.

Я видел несколько приложений (несколько плагинов для Chrome и менеджер загрузок), которые прослушивают событие буфера обмена. Как только сработает первый вызов, приложение откроет буфер обмена для просмотра данных, а второй вызов сброса завершится ошибкой.

Не нашел хорошего решения, кроме как написать свой собственный класс буфера обмена, который использует прямой API Win32 или вызвать setDataObject напрямую с false для хранения данных после закрытия приложения.

Я решил эту проблему для своего собственного приложения, используя собственные функции Win32: OpenClipboard (), CloseClipboard () и SetClipboardData ().

Ниже созданного мной класса-оболочки. Может ли кто-нибудь пожалуйста просмотреть его и скажи, правильно это или нет. Особенно, когда управляемый код работает как приложение x64 (я использую Any CPU в параметрах проекта). Что происходит, когда я подключаюсь к библиотекам x86 из приложения x64?

Спасибо!

Вот код:

public static class ClipboardNative
{
    [DllImport("user32.dll")]
    private static extern bool OpenClipboard(IntPtr hWndNewOwner);

    [DllImport("user32.dll")]
    private static extern bool CloseClipboard();

    [DllImport("user32.dll")]
    private static extern bool SetClipboardData(uint uFormat, IntPtr data);

    private const uint CF_UNICODETEXT = 13;

    public static bool CopyTextToClipboard(string text)
    {
        if (!OpenClipboard(IntPtr.Zero)){
            return false;
        }

        var global = Marshal.StringToHGlobalUni(text);

        SetClipboardData(CF_UNICODETEXT, global);
        CloseClipboard();

        //-------------------------------------------
        // Not sure, but it looks like we do not need 
        // to free HGLOBAL because Clipboard is now 
        // responsible for the copied data. (?)
        //
        // Otherwise the second call will crash
        // the app with a Win32 exception 
        // inside OpenClipboard() function
        //-------------------------------------------
        // Marshal.FreeHGlobal(global);

        return true;
    }
}

Я знаю, что это старый вопрос, но проблема все еще существует. Как упоминалось ранее, это исключение возникает, когда системный буфер обмена заблокирован другим процессом. К сожалению, существует множество инструментов для вырезания, программ для создания снимков экрана и инструментов для копирования файлов, которые могут блокировать буфер обмена Windows. Таким образом, вы будете получать исключение каждый раз, когда попытаетесь использовать Clipboard.SetText(str), когда такой инструмент установлен на вашем ПК.

Решение:

никогда не использовать

Clipboard.SetText(str);

использовать вместо

Clipboard.SetDataObject(str);

Это случилось со мной в моем приложении WPF. Я получил ошибку OpenClipboard (исключение из HRESULT: 0x800401D0 (CLIPBRD_E_CANT_OPEN)).

я использую

ApplicationCommands.Copy.Execute(null, myDataGrid);

решение - сначала очистить буфер обмена

Clipboard.Clear();
ApplicationCommands.Copy.Execute(null, myDataGrid);

Используйте версию WinForms (да, использование WinForms в приложениях WPF не вредно), она обрабатывает все, что вам нужно:

System.Windows.Forms.SetDataObject(yourText, true, 10, 100);

Это попытается скопировать ваш текст в буфер обмена, он останется после того, как ваше приложение существует, будет пытаться до 10 раз и будет ждать 100 мс между каждой попыткой.

Ref. https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.clipboard.setdataobject?view=netframework-4.7.2#System_Windows_Forms_Clipboard_SetDataObject_System_Object_System_Boolean_System_Int32_System_Int32_System_