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