Winforms文本框粘贴不可靠？

Question

我们在Winforms应用程序中有一个标准文本框,它在我们的开发环境中以正常方式(即粘贴)响应粘贴(右键单击菜单和CTRL + V).

在一个客户站点,粘贴大部分被完全忽略(表现得好像剪贴板中没有任何内容).我们使用TextBox的单行和多行版本测试了它,我们创建了一个只有几个TextBox的独立应用程序,在这个客户端站点上问题仍然存在.粘贴大部分都不起作用.

在进一步的测试中,我们发现只需在测试winforms应用程序中询问剪贴板的内容,它就会返回为空字符串.用记事本双重检查,我们发现剪贴板中确实有一些东西.

这是我们检查的内容:

• 在测试中我们确保剪贴板的来源是来自记事本或实际上是在文本框中,所以我们知道它不是来自HTML/Word的怪异东西
• 我们总是可以输入文本框,因此文本框不会允许修改
• 我们在剪贴板中使用大量和少量文本尝试过的文本数量没有任何区别
• 右键单击粘贴与CTRL + V:它们既可以工作也可以不工作 - 所以那些关于修复其中一个或哪一个的帖子对我们没有帮助
• 寻找模式我认为一旦它失败,一旦它重新启动,直到应用程序重新启动,但我不确定
• 当粘贴问题确实发生时,剪切和复制不受影响并继续工作
• 客户端的机器粘贴功能肯定适用于其他应用程序,记事本,Office等

请记住,完全相同的已编译应用程序始终在我们的开发机器上成功粘贴,并且偶尔会成功粘贴到客户的计算机上!这就是它如此神秘的原因.

在所有情况下,我们都通过粘贴到我们的应用程序旁边的记事本来验证剪贴板中有什么东西.

还有其他人看过这个和/或可以提出解释吗？

更新/进一步调查
它可能与线程有关吗？我们不会对线程做任何有趣的事情,我们也不必担心使用STAThread属性.但是MSDN页面说:

Clipboard类只能在设置为单线程单元(STA)模式的线程中使用.要使用此类,请确保使用STAThreadAttribute属性标记Main方法.

因此,在没有主线程的Winforms项目中 - 只是一个启动表单,你在哪里放置这个属性？为什么我们不在开发机器上需要它？为什么我们永远不需要在我们制作的无数其他Winforms应用程序中使用它？

Answer 1

你给的很少.这很可能是由程序中的问题引起的,更有可能是这是一个特定于用户机器的环境问题.

一些背景.Winforms应用程序中的TextBox控件与记事本用于编辑文本的组件完全相同.底层本机组件是Edit控件,从1.0版开始,它一直是Windows中的标准组件.请注意右键单击TextBox和记事本时获得的上下文菜单是如何相同的.在该菜单中的粘贴命令与按Ctrl + V之间没有区别,它们都会导致WM_PASTE消息被发送到本机Edit控件.其中内部处理剪贴板,该代码完全在您的范围之外,并且在您的程序中在记事本中操作相同.

线程公寓问题不大可能,客户应该也有复制命令的问题,你应该已经注意到它.在C#中,它由Main()方法的[STAThread]属性设置,它是在VB.NET中编译生成的.

有很多实用程序可能导致剪贴板行为不端.首先是剪贴板查看器,挂钩到剪贴板通知的程序.AddClipboardFormatListener()是底层的winapi函数.他们倾向于通过允许它存储多个项目或者给出剪贴板上的内容的另一个视图来执行诸如"增强"剪贴板之类的操作.它们倾向于通过不正确地将通知传递给下一个观看者或者通过不正确地注销它们来破坏观看者链来破坏机器的稳定性.这样一条断链本身就是导致"在记事本中工作正常,而不是在我的工作中".

这种问题当然很难诊断,通常在计算机用户彻底清理机器之前就不会得到解决.这是他的问题而不是你的问题总是难以传达,不能真正帮助你.

Answer 2

我有一个奇特的防火墙，它还可以根据每个应用程序阻止应用程序查看剪贴板中的数据。

它并不妨碍写作；该功能的目的是阻止恶意软件窃取可能最终出现在剪贴板中的重要信息，例如密码。
它还可以阻止任何给定的应用程序执行各种其他系统任务，例如截屏或使用默认系统浏览器导航到网页。

客户可能安装了类似的东西，并且规则中允许使用记事本。