Hi,
when you try "write" string like this 11234567890122345678912334456789012345556789 from clipboard, you'll have removed duplicated numbers and you gonna get 12345678901234567891234567890123456789.
Originally I found this bug, when I try "write" at external machine URL http:// , and it was written like htp://
--
KriS
Hi Kris
I couldn't reproduce exactly that behaviour, although in my tests I saw that characters definitely can be dropped sometimes. It can be extremely timing dependent; depending on the performance / load of the remote machine and how quickly we push the input events to it.
Regardless - we've spotted an optimization that should improve things. I'll hope to integrate that for the next release and we'll see if it fixes things for you. I'll post back here with news.
Thanks for the bug report and kind regards,
Richard Markievicz
Hi,
strange.. but me neither, only because I don't have "type clipboard" option available. (it's grayed out)
It was something like this:
--
KriS
Hi Kris
The "Type clipboard..." function will only be available if the local clipboard contains less than 256 characters of text. It's an arbitrary limit chosen to allow convenient entry of short strings (e.g. passwords, URLs) when the clipboard is not available (for example, on the Windows logon screen). The limitation is because processing the text into key events can be surprisingly resource intensive (especially on Linux servers).
We are working on improving clipboard robustness when you are also working over RDP or have concurrent remote sessions. I can't say if those improvements will be in the next release (2020.2.0) but if not, they should be in the next minor release after that.
Thanks and kind regards,
Richard Markievicz
Hi Kris
Wayk Now 2020.2.0 is now available for download, and contains some improvements for "Type Clipboard Contents". Note that the changes are server-side, so it's the remote machine that needs to be updated in order to benefit. I'd encourage you to keep using the feature and let us know if you continue to see issues.
Thanks and kind regards,
Richard Markievicz