newRPL-Desktop past and copy

[Klaus]

I am trying again because there is no solution yet.
The problem: I copy to PC(Win10) and paste into newRPL desktop, but not the other way around (newRPL desktop > PC(Win10).
Is it normal, or is there a trick for it?

[Claudio L.]

(12-21-2020 03:50 PM)Klaus Wrote:  I am trying again because there is no solution yet.
The problem: I copy to PC(Win10) and paste into newRPL desktop, but not the other way around (newRPL desktop > PC(Win10).
Is it normal, or is there a trick for it?

No tricks, but Ctrl+C for copy and Ctrl+V for paste doesn't work. Use the menu item "Copy Level 1" to do it, then you should be able to paste in other applications.
I just tried it in Linux (I don't have a Win machine at hand right now) and it worked fine.

[Klaus]

That's exactly how I do it - copy Level 1! And unfortunately that doesn't work on Win10. Thank you.

[_nmr_]

(12-22-2020 11:20 AM)Klaus Wrote:  That's exactly how I do it - copy Level 1! And unfortunately that doesn't work on Win10. Thank you.

I have a win10 machine. This procedure works. For example, put expression « 1 2 + » and then press ENTER. Now expression is on the stack level 1 and may be copied to clipboard by "copy level 1".

[Klaus]

Hello,
That's exactly how I do it! But if I want to copy this printout to a text window to print it, there is nothing on the clipboard. Maybe it prevents a setting on my PC.

[Claudio L.]

(12-22-2020 01:48 PM)Klaus Wrote:  Hello,
That's exactly how I do it! But if I want to copy this printout to a text window to print it, there is nothing on the clipboard. Maybe it prevents a setting on my PC.

newRPL uses the MIME type "text/plain;charset=utf-8", which is universally recognized, it should not give you trouble in any way, but...
I just fired up a VM with the latest Windows 10, installed newRPL Desktop from the sourceforge site and tested copy/pasting.
Here's what I found:
Copy/Paste works fine both ways between 2 different instances of newRPL Desktop (this is binary copy in newRPL internal format).
Copy from newRPL Desktop works if you paste to an old-ish windows application: I tested my old Word and Excel 2007, and the HP Prime Connectivity kit for example.
New applications (even the basic Notepad) seem to ignore the clipboard content (which is obviously there, you can see it as "blank" if you use the Win+V key to get the clipboard history). I think Windows 10 changed something and started ignoring this MIME type.
Thanks for letting me know, I'll do some more research, not sure which MIME type MS wants to impose on us now...

[Klaus]

Thank you, it is good to know that this is the cause. You may be able to solve the problem in a next release. That would be a good thing. Best regards!

[Thomas Okken]

SetClipboardData(CF_UNICODETEXT, ...) should be compatible with everything, it's one of the standard formats in Windows. This uses UTF-16. I didn't know you could even use UTF-8, but it's certainly not guaranteed to be supported by everything. In files, yes, but on the clipboard, no.

It's not a big problem since the conversion is easy with MultiByteToWideChar() and WideCharToMultiByte()...

[Claudio L.]

(12-22-2020 05:40 PM)Thomas Okken Wrote:  SetClipboardData(CF_UNICODETEXT, ...) should be compatible with everything, it's one of the standard formats in Windows. This uses UTF-16. I didn't know you could even use UTF-8, but it's certainly not guaranteed to be supported by everything. In files, yes, but on the clipboard, no.

It's not a big problem since the conversion is easy with MultiByteToWideChar() and WideCharToMultiByte()...

Not so simple. I use Qt because the same code is newRPL Desktop for Windows, Linux, MacOS and even Android. I don't want direct Windows API calls, it's all abstracted in the library and outside my control.
NewRPL uses multi format data in the clipboard. Right now it uses 3 separate formats simultaneously: text/plain with utf8 charset, HTML and binary. Plain text is what Linux and MacOS like better. Windows didn't accept this, for windows plain text was just ASCII, all Unicode characters were messed up.
But then Windows had Rich Text (which went obsolete long ago) and HTML, so newRPL uses HTML (which is utf8 encoded by default). Windows preferred the HTML when available so it worked well.
The third format is a binary object to avoid any loss of information when you copy/ paste between newRPL instances.

This worked fine even on Windows 10 until not sure when (must've been one of the last big updates). From doing some additional testing, it seems that now Windows dropped support for pasting HTML in most of its controls, and is not accepting the plain text with UTF8 either (plain text without indicating encoding is accepted, or perhaps it's converted to UTF-16 by Qt internally). This may be a security thing perhaps, who knows. Old applications like the HP Prime Connectivity kit which have a "Win7" styling work well, including Unicode characters because they paste the HTML version of the data in the clipboard.

Funny enough, now the plain text in Windows 10 is no longer ASCII, it's fully Unicode. I just tested it and all characters were pasted as they should on all Win10 controls and in Notepad.

So I guess I'll just eliminate the HTML, and leave the text as plain text, I still need more testing to make sure it doesn't break Linux or Android. Problem is, this will likely break support for Windows 7... I have a lot of testing to do to make sure I get this right, perhaps adding a 4th format...

[Thomas Okken]

Windows has used UTF-16 on the clipboard ever since Windows NT (although it wasn't called UTF-16 yet when Microsoft adopted it). It would make sense if Qt performed the UTF-8 to UTF-16 conversion automatically on Windows, assuming the Qt APIs are UTF-8 based.

[Claudio L.]

(12-23-2020 09:50 AM)Thomas Okken Wrote:  Windows has used UTF-16 on the clipboard ever since Windows NT (although it wasn't called UTF-16 yet when Microsoft adopted it). It would make sense if Qt performed the UTF-8 to UTF-16 conversion automatically on Windows, assuming the Qt APIs are UTF-8 based.

It does, but in order to simplify the API, it only has a SetText() function and internally it's all a black box, not particularly well documented. Qt uses an abstract type QString, the actual encoding is completely opaque and all conversions are transparent (or supposed to be).
In older Qt versions the clipboard SetText() function was mapped to plain text (ASCII) in Windows. When I originally did it it was not pasting any Unicode characters in Windows (but OK on Linux) and this made it useless for coding in RPL.
My workaround using HTML worked great until now that pasting HTML has been dropped by Windows, but after further testing SetText() from Qt is now working well on Windows, so problem solved. I just pushed my fix in the repos, it will come out in the next release.

[Klaus]

Have found a solution for the time being: LibreOffice Writer takes the copied text from the newRPL desktop from the seemingly empty Windows clipboard.

[Claudio L.]

(01-23-2021 08:38 AM)Klaus Wrote:  Have found a solution for the time being: LibreOffice Writer takes the copied text from the newRPL desktop from the seemingly empty Windows clipboard.

Open/LibreOffice is one of the open source programs I tested when I originally worked on copy/paste. Good to hear it still works.
But the problem was fixed a while ago, when you asked. I just didn't get around to publish an updated ROM and Desktop yet (sorry). The next release will have 2 Desktop versions: one with 50g look and one with Prime look (user preference, really, it's the same under the hood). Right now we are in the middle of everything so we are not quite ready for an official update just yet.

Copy/Paste already works well, though...

[Klaus]

Thank you very much, I'm happy