Search code examples
.netwinformstextboxcut-and-paste

Winforms textbox paste unreliable?


We have a standard textbox in a Winforms application which responds to paste (both right-click menu and CTRL+V) in the normal way (ie it pastes) in our dev environment.

At one customer site the paste is mostly completely ignored (behaves as if there's nothing in the clipboard). We've tested it with both single line and multiline versions of the TextBox and we've created a standalone app with just a couple of TextBoxes and on this one client site the problem persists. Pasting mostly doesn't work.

In further testing we find that simply asking for the clipboard's content within a test winforms app, it comes back as empty string. Double checking with Notepad we find there's definitely something in the clipboard.

Here's what we've checked:

  • In tests we ensure the source of the clipboard is from Notepad or indeed within the textbox itself so we know it isn't something freaky from HTML/Word
  • We can always type into the textbox, so it isn't as if the textbox isn't allowing modifications
  • Quantity of text we've tried it with large and small amounts of text in the clipboard, makes no difference
  • Right-click paste versus CTRL+V: they either both work or neither work - so all those posts out there which are about fixing either one or the other are no help to us
  • Looking for patterns I think that once it's failed once it doesn't work again until the app is restarted but I'm not sure
  • When the paste problem does occur, cut & copy are unaffected and continue to work
  • Client's machines paste function definitely works on their other apps, Notepad, Office etc

Remember that the very same compiled application always pastes successfully on our dev machines and does occasionally paste successfully on the customer's machines! This is what makes it so mysterious.

In all cases we've verified that there is something in the clipboard by pasting into Notepad alongside our app.

Has anyone else has seen this and/or can suggest an explanation?

Update/Further investigation
Could it be that it's something to do with threading? We don't do anything interesting with threading and we've never had to worry about using an STAThread attribute. But the MSDN page says:

The Clipboard class can only be used in threads set to single thread apartment (STA) mode. To use this class, ensure that your Main method is marked with the STAThreadAttribute attribute.

So, in a Winforms project with no main thread - just a startup form, where do you put this attribute? And why don't we need it on the dev machines? And how come we've never needed to use it on any of countless other Winforms apps we've made?


Solution

  • I have a fancy firewall that is also able block applications from looking at data in the clipboard, on per-application basis.

    It does not prevent writing; the point of the feature is to stop malware from stealing important information that might end up in the clipboad, such as a password.
    It can also block any given application from doing various other system tasks, e.g. taking a screenshot or navigating to a web page with the default system browser.

    The customer might have something like that installed, with Notepad allowed in the rules.