我们在Winforms应用程序中有一个响应的标准文本框 糊 （正确的方式（即粘贴）在我们的开发环境中（右键菜单和CTRL + V）。
在一个客户站点，粘贴大部分被完全忽略（表现得好像剪贴板中没有任何内容）。我们使用TextBox的单行和多行版本测试了它，我们创建了一个只有几个TextBox的独立应用程序，在这个客户端站点上问题仍然存在。粘贴大部分都不起作用。
在进一步测试中，我们发现只需在测试winforms应用程序中询问剪贴板的内容，它就会返回为空字符串。用记事本仔细检查，我们发现有 无疑 剪贴板中的东西。
这是我们检查的内容：
- 在测试中我们确保 资源 剪贴板是从记事本或实际上在文本框本身，所以我们知道它不是HTML / Word中的怪异东西
- 我们总是可以输入文本框，因此文本框不会允许修改
- 文字数量 我们已经在剪贴板中使用大量和少量文本进行了尝试，没有任何区别
- 右键单击粘贴与CTRL + V：他们既可以工作也可以不工作 - 所以那些关于修复其中一个或另一个的所有帖子对我们没有帮助
- 寻找模式 一世 认为 一旦它失败，一旦它重新启动，直到应用程序重新启动，但我不确定
- 当粘贴问题确实发生时，剪切和复制不受影响并继续工作
- 客户端的机器粘贴功能肯定适用于其他应用程序，记事本，Office等
请记住，完全相同的编译应用程序始终在我们的开发机器上成功粘贴并且确实如此 偶尔 在客户的机器上成功粘贴！这就是它如此神秘的原因。
在所有情况下，我们都通过粘贴到我们的应用程序旁边的记事本来验证剪贴板中有什么东西。
有没有其他人看过这个和/或可以提出解释？
更新/进一步调查
难道它与线程有关吗？我们不会对线程做任何有趣的事情，我们也不必担心使用STAThread属性。但是MSDN页面说：
Clipboard类只能在设置为单线程的线程中使用
公寓（STA）模式。要使用此类，请确保使用Main方法
标有STAThreadAttribute属性。
因此，在没有主线程的Winforms项目中 - 只是一个启动表单，你在哪里放置这个属性？为什么我们不在开发机器上需要它呢？为什么我们永远不需要在我们制作的无数其他Winforms应用程序中使用它？
我有一个花哨的防火墙，它也能阻止应用程序在每个应用程序的基础上查看剪贴板中的数据。
它不会妨碍写作;该功能的目的是阻止恶意软件窃取可能最终出现在剪贴板中的重要信息，例如密码。
它还可以阻止任何给定的应用程序执行各种其他系统任务，例如，使用默认系统浏览器截取屏幕截图或导航到网页。
客户可能安装了类似的东西，规则中允许使用记事本。
你提供的东西很少。这很可能是由程序中的问题引起的，更可能是这是一个特定于用户机器的环境问题。
一些背景。 Winforms应用程序中的TextBox控件是 精确 记事本用于允许您编辑文本的相同组件。底层本机组件是Edit控件，从1.0版开始，它一直是Windows中的标准组件。请注意右键单击TextBox和记事本时获得的上下文菜单是如何相同的。在该菜单中的粘贴命令与按Ctrl + V之间没有区别，它们都会导致 WM_PASTE消息 要发送到本机Edit控件。其中内部处理剪贴板，该代码完全在您的范围之外，并且在您的程序中在记事本中操作相同。
线程公寓问题不大可能，客户应该也有复制命令的问题，你应该已经注意到它。在C＃中，它由Main（）方法的[STAThread]属性设置，它是在VB.NET中编译生成的。
有很多实用程序可能导致剪贴板行为异常。首先是剪贴板查看器，挂钩到剪贴板通知的程序。 AddClipboardFormatListener（）是底层的winapi函数。他们倾向于通过允许它存储多个项目或者给出剪贴板上的内容的另一个视图来执行诸如“增强”剪贴板之类的操作。他们倾向于通过不正确地将通知传递给下一个观看者或通过不正确地注销自己来破坏观看者链来破坏机器的稳定性。这样一条断链本身就是导致“在记事本中工作正常，而不是在我的工作中”。
当然，这类问题很难诊断，通常在计算机用户彻底清理机器之前无法解决。这是他的问题，而不是你的问题总是难以传达，不能真正帮助你。
有时候，其他第三方应用程序可能正在控制你的剪贴板 SnagIt的 第三方应用程序可能有用于剪贴板的过滤器，用于记事本和其他基于Windows的应用程序等标准对象控件。
你可以做的是你必须找到客户端机器上的任何其他应用程序可以访问剪贴板。您可以通过任务管理器或运行过程进行检查。它可能会帮助你。
我遇到过与Snagit应用程序类似的问题。此应用程序阻止我的程序设置剪贴板文本供自己使用。