Closed longborough closed 6 years ago
Thanks for pointing this out. This sounds like a bug in clipboard-win, which this crate uses to provide support for Windows platforms. I'd suggest filing this issue there, and commenting on this issue once it's fixed upstream so I can update the dependency version.
Additional information that might be helpful: What program(s) are you copying the string from? It might be the case that some senders are appending the null byte, but not others; are you able to identify the circumstances which lead to the null byte being appended more precisely?
The ideal information would be some specific string s1 such that ctx.set_contents(s1).unwrap(); let s2 = ctx.get_contents().unwrap(); assert_eq!(s1, s2);
fails with an assertion error, but if you can't reduce it that far, a list of what combinations you've tried would be helpful too.
Thanks. Yes, I have only seen this behaviour when using these steps to place something on the clipboard:
I'll put together a simple example to report this @ clipboard-win; this may take a few days. I'll report back with any news.
Hi, Avi, This has now been fixed. See this issue for details. Thanks for your help.
First, many thanks for clipboard. I'm very much a Rust newbie, and it's an important component of my first self-imposed training exercise.
Second, I have no idea how "appropriate" this suggestion is, so I won't be in an way miffed if you find it too special a case and close it as WontFix. So here goes:
Under some circumstances, but not always, Windows appears to append a null byte (I think) to the contents of the clipboard. The specific case I have found is when marking and copying from a command window.
I had marked and copied
2018.074
.My program rejected it (debug formatting):
Date "2018.074\u{0}" is invalid
.Clearly I can tidy this up myself, but I wonder whether this would be more generally useful.