У нас есть стандартное текстовое поле в приложении Winforms, которое отвечает на пастой (как правой кнопкой мыши, так и CTRL + V) обычным способом (то есть, пасты) в нашей среде разработки.Winforms textbox paste ненадежен?
На одном сайте клиента паста в основном полностью игнорируется (ведет себя так, как будто в буфере обмена ничего нет). Мы протестировали его как с однострочными, так и с многострочными версиями TextBox, и мы создали автономное приложение только с несколькими текстовыми блоками, и на этом одном клиентском сайте проблема сохраняется. Вставка в основном не работает.
В ходе дальнейшего тестирования мы обнаруживаем, что просто запрашиваем содержимое буфера обмена в тестовом winforms приложении, оно возвращается как пустая строка. Двойная проверка с помощью Блокнота мы находим определенно что-то в буфере обмена.
Вот что мы проверили:
- В тестах мы обеспечиваем источник из буфера обмена из блокнота или даже в текстовом поле сам, поэтому мы знаем, что это не что-то причудливым из HTML/Слова
- мы всегда можно ввести в текстовое поле, так что это не так, если текстовое поле не позволяет модификации
- Количество текста мы пытались его с большими и малыми объемами текста в буфер обмена, делает без разницы
- правой кнопки мыши вставить против CTRL + V: они либо оба работают или не работают - так что все эти сообщения, которые там находятся около фиксируя либо один, либо другие являются не помогут нам
- Цели знакомства моделей Я думаю, что когда-то это не удалось, когда он не работает, пока приложение не будет перезапущен, но я не уверен, что
- Когда возникает проблема пасты, вырезать & копия не изменяются и продолжают работать
- машины Клиента функция пасты определенно работает над другими приложениями, «Блокнотом», «Офис» и т. д.
Помните, что тот же компилируется приложение всегда успешно приклеивает на наших Дев машинах и делает иногда паста успешно на машинах клиента! Это то, что делает его настолько загадочным.
Во всех случаях мы проверили, что есть что-то в буфере обмена, вставив в блокнот вместе с нашим приложением.
Кто-нибудь еще видел это и/или может предложить объяснение?
Update/Дальнейшие исследования
Может быть, это что-то делать с потоками? Мы не делаем ничего интересного в потоковом режиме, и нам никогда не приходилось беспокоиться об использовании атрибута STAThread. Но страница MSDN говорит:
Класс Clipboard можно использовать только в потоках, установленных в режиме одного потока квартиры (STA). Чтобы использовать этот класс, убедитесь, что ваш Основной метод отмечен атрибутом STAThreadAttribute.
Итак, в проекте Winforms без основного потока - только стартап-форма, где вы поместите этот атрибут? И почему нам это не нужно на dev-машинах? И почему нам никогда не приходилось использовать его в любом из бесчисленных других приложений Winforms, которые мы создали?
Вы обрабатываете событие вставки самостоятельно в коде? Если да, можете ли вы включить этот метод? –
нет, это очень ваниль. мы полагаемся на встроенный патч winforms textbox – hawbsl
, если машины-разработчики не выдают никаких проблем и делают клиент, очевидно, что-то другое. В [этой теме] (http://social.technet.microsoft.com/Forums/windows/en-US/5bbc11e8-ca2d-41ac-b640-d66ce971f58f/copy-paste-clipboard-issues-not-working?forum= w7itprogeneral) имеются упоминания о инструментах управления системой/памятью, которые спорадически опустошают кеш буфера обмена. Это может быть растяжкой, но эй, кто знает –