Ошибка при вызове openclipboard
Ошибка CLIPBRD_E_CANT_OPEN при установке буфера обмена из .NET
Почему следующий код иногда вызывает исключение с содержимым «CLIPBRD_E_CANT_OPEN»:
Это обычно происходит в первый раз, когда буфер обмена используется в приложении, а не после этого.
6 Ответов
Это вызвано ошибкой / функцией в буфере обмена Terminal Services (и возможными другими вещами) и реализацией буфера обмена .NET. Задержка при открытии буфера обмена вызывает ошибку, которая обычно проходит в течение нескольких миллисекунд.
Решение состоит в том, чтобы попробовать несколько раз в цикле и спать между ними.
На самом деле, я думаю, что это вина Win32 API .
Чтобы установить данные в буфер обмена, вы должны сначала открыть его . Только один процесс может одновременно открыть буфер обмена. Поэтому, когда вы проверяете , открыт ли буфер обмена по какой-либо причине другим процессом, ваша попытка открыть его будет неудачной.
Просто так получилось, что Terminal Services отслеживает буфер обмена, и в более старых версиях Windows (pre-Vista) вам нужно открыть буфер обмена, чтобы увидеть, что находится внутри. что в конечном итоге блокирует вас. Единственное решение-дождаться, пока Terminal Services закроет буфер обмена, и повторить попытку.
Однако важно понимать, что это не является специфичным для Terminal сервисов: это может произойти с чем угодно. Работа с буфером обмена в Win32-это гигантское состояние гонки. Но, поскольку по замыслу вы должны только возиться с буфером обмена в ответ на ввод пользователя, это обычно не представляет проблемы.
Я знаю, что этот вопрос стар, но проблема все еще существует. Как уже упоминалось ранее, это исключение возникает, когда системный буфер обмена блокируется другим процессом. К сожалению, есть много инструментов для обрезки, программ для скриншотов и инструментов копирования файлов, которые могут блокировать буфер обмена Windows. Таким образом, вы будете получать исключение каждый раз, когда вы пытаетесь использовать Clipboard.SetText(str) , когда такой инструмент установлен на вашем PC.
никогда не использовать
используйте вместо этого
На самом деле здесь может быть и другая проблема. Вызов фреймворка (как WPF, так и WinForm вкусов) к чему-то вроде этого (код от reflector):
Обратите внимание, что SetDataObject всегда вызывается с true в этом случае.
Внутренне это вызывает два вызова win32 api, один для установки данных и один для удаления их из вашего приложения, чтобы они были доступны после закрытия приложения.
Я видел несколько приложений (некоторые плагины chrome и менеджер загрузок), которые прослушивают событие буфера обмена. Как только произойдет первый вызов, приложение откроет буфер обмена, чтобы посмотреть данные, а второй вызов для сброса завершится неудачей.
Не нашел хорошего решения, кроме как написать свой собственный класс буфера обмена, который использует прямой win32 API или вызвать setDataObject напрямую с false для хранения данных после закрытия приложения.
Я решил эту проблему для моего собственного приложения, используя собственные функции Win32: OpenClipboard(), CloseClipboard() и SetClipboardData().
Ниже класса обертки, который я сделал. Может ли кто-нибудь, пожалуйста , просмотреть его и сказать, является ли он правильным или нет . Особенно когда управляемый код выполняется как приложение x64 (я использую любой CPU в параметрах проекта). Что происходит, когда я ссылаюсь на библиотеки x86 из приложения x64?
Это происходит со мной в моем приложении WPF. Я получил OpenClipboard сбой (исключение из HRESULT: 0x800401D0 (CLIPBRD_E_CANT_OPEN)).
решение состоит в том, чтобы сначала очистить буфер обмена
Похожие вопросы:
Кто-нибудь заметил, что если вы извлекаете HTML из буфера обмена, он получает неверную кодировку и вводит странные символы? Например, выполнение такой команды: string s = (string).
При каких обстоятельствах функция Win32 API OleGetClipboard() выйдет из строя и вернет CLIPBRD_E_CANT_OPEN ? Дополнительная информация: я помогаю с исправлением ошибки Firefox. Подробности здесь.
У меня возникли проблемы с буфером обмена, и я получаю это сообщение об ошибке каждый раз, когда я пытаюсь сделать операцию копирования / вставки из файла Excel. Код разрывается на.
Мне нужно сделать простое приложение-службу, которое будет привязываться к буферу обмена Windows. В частности, каждый раз, когда происходит операция копирования / вырезания, я хочу проанализировать.
Я делаю это в C#,, но, я думаю,это не языковая проблема. У меня есть пример кода о том, как определить, когда содержимое буфера обмена изменяется. Теперь я хочу изменить текст, который только что.
Я пишу надстройку C# Word 2013, которая запутывает содержимое буфера обмена, если копируемое содержимое находится в управляемом приложении Word. У меня есть несколько вопросов. Я столкнулся с.
Ошибка CLIPBRD_E_CANT_OPEN при настройке буфера обмена из .NET.
Почему следующий код иногда вызывает исключение с содержимым «CLIPBRD_E_CANT_OPEN»:
Обычно это происходит при первом использовании буфера обмена в приложении, а не после этого.
.net clipboard wpf
6 ответов
29 Решение Tadmas [2008-09-16 05:21:00]
На самом деле, я думаю, что это ошибка Win32 API.
Чтобы установить данные в буфер обмена, сначала откройте его. Только один процесс может открывать буфер обмена одновременно. Таким образом, когда вы проверяете, если какой-либо другой способ открывает буфер обмена по какой-либо причине, ваша попытка открыть его не удастся.
Так получилось, что службы терминалов отслеживают буфер обмена, а в старых версиях Windows (pre-Vista) вам нужно открыть буфер обмена, чтобы увидеть, что внутри. что в конечном итоге блокирует вас. Единственное решение — дождаться, когда Terminal Services закроет буфер обмена и повторит попытку.
Важно понимать, что это не относится к службам терминалов, однако: это может произойти с чем угодно. Работа с буфером обмена в Win32 — это гигантское состояние гонки. Но, поскольку по дизайну вы должны только гадать с буфером обмена в ответ на ввод пользователя, это обычно не представляет проблемы.
Это вызвано ошибкой/функцией в буфере обмена служб терминалов (и, возможно, другими вещами) и внедрением .NET в буфер обмена. Задержка при открытии буфера обмена вызывает ошибку, которая обычно проходит в течение нескольких миллисекунд.
Решение состоит в том, чтобы попробовать несколько раз в цикле и спать между ними.
8 pr0gg3r [2016-08-24 16:46:00]
Я знаю, что этот вопрос старый, но проблема все еще существует. Как упоминалось ранее, это исключение возникает, когда системный буфер обмена блокируется другим процессом. К сожалению, многие инструменты для съёмки, программы для скриншотов и инструменты копирования файлов, которые могут блокировать буфер обмена Windows. Таким образом, вы получите исключение каждый раз, когда пытаетесь использовать Clipboard.SetText(str) , когда такой инструмент установлен на вашем ПК.
никогда не используйте
На самом деле может быть и другая проблема. Рамочный вызов (как WPF, так и winform) к чему-то вроде этого (код от рефлектора):
Обратите внимание, что SetDataObject всегда вызывается с истинным в этом случае.
Внутренне, что вызывает два вызова win32 api, один для установки данных и один для его очистки от вашего приложения, чтобы он был доступен после закрытия приложения.
Я видел несколько приложений (некоторые хром-плагины и диспетчер загрузки), которые прослушивают событие буфера обмена. Как только первый звонок ударит, приложение откроет буфер обмена, чтобы просмотреть данные, а второй вызов сбросить не удастся.
Не нашли хорошего решения, кроме как написать собственный класс буфера обмена, который использует прямой API win32 или вызвать setDataObject напрямую с помощью false для хранения данных после закрытия приложения.
4 Mar [2015-05-11 13:45:00]
Я решил эту проблему для своего собственного приложения, используя собственные функции Win32: OpenClipboard(), CloseClipboard() и SetClipboardData().
Ниже класс обертки, который я сделал. Может ли кто-нибудь просить проверить его и сообщить, правильно ли он или нет. Особенно, когда управляемый код работает как приложение x64 (я использую любой CPU в вариантах проекта). Что происходит, когда я ссылаюсь на библиотеки x86 из приложения x64?
0 MaxyDav [2017-05-11 11:36:00]
Это происходит со мной в моем приложении WPF. У меня возникла ошибка OpenClipboard (исключение из HRESULT: 0x800401D0 (CLIPBRD_E_CANT_OPEN)).
решение состоит в том, чтобы сначала очистить буфер обмена
Ошибка при вызове openclipboard
Опции темы
| Adept |
| |||
 Бывалый Профиль Репутация: нет
Clipboard.clear() выкидывает исключение COMExeption Получается Clipboard занят другим процессом и удается до него достучаться.
| ||||
|
Загрузка .
| wester |
| ||
|
| Akbar |
| ||
|
| ||
Используйте теги [code=csharp][/code] для подсветки кода. Используйтe чекбокс «транслит» если у Вас нет русских шрифтов. |
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, mr.DUDA, THandle.
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) |
| 0 Пользователей: |
| « Предыдущая тема | Общие вопросы по .NET и C# | Следующая тема » |
[ Время генерации скрипта: 0.0969 ] [ Использовано запросов: 21 ] [ GZIP включён ]
c# — ошибка при вызове openclipboard исключение из hresult 0x800401d0 clipbrd_e_cant_open))
Ошибка OpenClipboard при копировании данных из WPF DataGr > (6)
Для этой цели есть подпись события / метода DataGrid CopyingRowClipboardContent (отправитель объекта, DataGridRowClipboardEventArgs e) и более надежна, чем Clipboard.SetDataObject (данные) или Clipboard.SetText (данные).
Вот как это использовать.
Установите «FullRow» в режиме SelectionUnit для DataGrid, называемого myDataGrid
У нас есть метод myDataGrid_CopyingRowClipboardContent, который вызывается для каждой строки в dataGrid для копирования его содержимого в буфер обмена. Например, для datagrid с семью строками это называется семь раз.
У меня есть приложение WPF, использующее datagrid. Приложение отлично работало, пока я не установил предварительный просмотр Visual Studio 2012 и Blend + SketchFlow. Теперь, когда я пытаюсь скопировать данные из сетки в буфер обмена с помощью Ctrl + C (в любом приложении), я получаю следующее исключение:
Это действительно раздражает.
Я видел некоторые ссылки на эту проблему here и в разных местах в Интернете, без реального решения.
Я могу проверить, заблокирован ли буфер обмена, когда это исключение создано в Visual Studio, поскольку я не мог скопировать вставку сообщения (должен был записать его в файл). Кроме того, буфер обмена не был заблокирован до начала процесса копирования.
Как решить эту проблему?
Добавив свой ответ из упомянутого вопроса SO для справки —
Технически только 1 процесс может открыть буфер обмена, поэтому, если другой процесс откроет его, последующие запросы потерпят неудачу, пока первый не освободит буфер обмена. Это было похоже на класс WinForms Clipboard, в котором он повторил набор с задержкой между каждой попыткой, но класс буфера обмена WPF не делает этого, поэтому, если он не сработает при первом показе исключения. Даже тогда мы должны, вероятно, поймать исключение и поднять ошибку операции с буфером обмена, если он все еще не работает.
То же самое объясняется, и некоторые способы исправить это упоминаются в этом итальянском блоге —
После обсуждения форума MSDN можно предположить, что это может быть проблема с машиной —
У меня была та же проблема при копировании ячеек Excel в буфер обмена и получение данных из буфера обмена в виде строки HTML.
Вы можете использовать (while-try-catch), как в приведенном ниже коде.
Кроме того, вы можете иметь счетчик в то while если цикл более 10 раз или более, возникает исключение. Я тестирую его максимальный счетчик — это одно и одноразовое управление буфером.
У меня была такая же проблема с RichTextBox. Следующий код разбился случайным образом:
Кажется, что лучше использовать System.Windows.Controls.RichTextBox.Copy
У меня также была эта проблема в WPF 4.0 и 4.5, так как я установил TeraCopy (Windows 7, 64-разрядный). У каждого Clipboard.SetText () произошел сбой в System.Runtime.InteropServices.COMException.
Моим первым решением было удалить TeraCopy — это сработало, но мне нравится это приложение, поэтому мне пришлось искать другое решение для решения этой проблемы. Решение заключалось в замене
У меня тоже возникла проблема в приложении, где я копирую информацию в буфер обмена, когда пользователи просматривают ListBox. Скопированная информация относится к выбранному элементу и позволяет им вставлять его (указанную информацию) в другие приложения для удобства. Иногда я получаю CLIPBRD_E_CANT_OPEN на некоторых пользовательских системах, но не на других.
Хотя я до сих пор не смог исправить конфликт, мне удалось создать код, чтобы найти приложение, вызывающее конфликт. Я бы хотел по крайней мере поделиться этим кодом в надежде, что это поможет кому-то. Я добавлю инструкцию using , атрибуты и метод, которые я создал, чтобы найти объект Process of the Culprit. Из элемента « Процесс» вы можете получить имя процесса, PID, заголовок главного окна (если оно есть) и другие потенциально полезные данные. Вот строки кода, которые я добавил без кода, который его вызывает. ( ПРИМЕЧАНИЕ. Ниже фрагмента кода у меня есть еще один лакомый кусочек для обмена):
ДРУГОЕ ПРИМЕЧАНИЕ. Еще одна вещь, которую я изменил, которая упростила мой код, заключалась в том, чтобы преобразовать из System.Windows.Clipboard в System.Windows.Forms.Clipboard (см. Класс System.Windows.Forms.Clipboard ), поскольку последний имеет 4- параметр SetDataObject (), который включает в себя счетчик повторов и задержку повтора в миллисекундах. Это, по крайней мере, устранило некоторые из повторных шумов из моего кода.
Ваш пробег может меняться . плюс могут быть побочные эффекты, которые я еще не наткнулся, поэтому, если кто-нибудь знает о них, прокомментируйте. В любом случае, надеюсь, это окажется полезным для кого-то.
