String copy strangeness

[Neil Pate]

Anyone want to guess what happens if you try and copy and paste the contents of this string to some other application like Notepad?

String Copy Weirdness.vi

[Gribo]

Why do you have a null  (\00) in the middle?

[Neil Pate]

Nice spot. It is a perfectly valid character though.

[crossrulz]

It may be valid, but for any application that uses C-style strings, the NULL character ends the string.

[Neil Pate]

1 hour ago, crossrulz said:

It may be valid, but for any application that uses C-style strings, the NULL character ends the string.

Yes I know. But this is LabVIEW which does not have null terminated strings. That is what makes this strange. 

[crossrulz]

23 minutes ago, Neil Pate said:

Yes I know. But this is LabVIEW which does not have null terminated strings. That is what makes this strange. 

Yeah, but you are talking about pasting into other applications.  How are they interfacing with the clipboard?  We have no control over that.  You will see this same issue if you try to interact with a DLL that uses C-style strings (data will be cut off at the NULL character).

I should also state that the NULL is copied over if you paste into another LabVIEW string control (yes, I just tested it).

[Neil Pate]

9 minutes ago, crossrulz said:

Yeah, but you are talking about pasting into other applications.  How are they interfacing with the clipboard?  We have no control over that.  You will see this same issue if you try to interact with a DLL that uses C-style strings (data will be cut off at the NULL character).

I should also state that the NULL is copied over if you paste into another LabVIEW string control (yes, I just tested it).

Nope. If I start with this same string in notepad or some other application it copies and pastes correctly. 

For example notepad to notepad++ works correctly. 

I classify this as a bug. The string in LabVIEW includes all the characters, it should copy them correctly. I don't think this is a limitation of the windows API 

[Gribo]

LV to notepad++ doesn't work -> Notpad++ uses C style strings for the paste from clipboard.

LV to MS Word & Excel 365 doesn't work -> Same as above.

It seems the LV to LV path allows null in the middle of a string, while the LV to Windows path doesn't.

[Neil Pate]

1 hour ago, Gribo said:

 Notpad++ uses C style strings for the paste from clipboard

I don't think so as I can copy and paste with null chars just fine using notepad to notepad++

[Gribo]

Yes, it is probably the windows clipboard that does the string sanitizing.

Strangely, from Notepadd++ to LV2020, I get a space instead of \00.

Edited January 13, 2022 by Gribo

[Neil Pate]

ok ok I take it all back. Seems like a Windows thing.

Copying this from Notepad++ to Notepad results in this

which if I then copy back to Notepad++ I get this

I guess some applications sanitise the string before sending to the windows API.

[Rolf Kalbermatter]

There is another "little" culprit, and its the most likely reason for this discrepancy. LabVIEW only uses 8-bit ASCII text and accordingly only posts a so called ANSI (that's what Windows calls it when you use an 8-bit codepage encoding) to the clipboard.

Notepad and Notepad++ are definitely Unicode applications. While they may enumerate clipboard data formats and only request ANSI if there is no Unicode string format in the clipboard, they almost certainly will use the MultiByteToWideChar() Windows API to translate the text, and if they do request Unicode anyhow, Windows will be helpfully translating it for them using that function. But this function will terminate converting a string on the first occurrence of a NULL character. Most code doesn't bother to check if the translated code has consumed all the input bytes. It's also not trivial to do, as the function returns how many codepoints it placed into the output buffer, but that does not have to match the number of input bytes, since some ANSI encodings can use more than one byte for some characters, and the used UTF-16 standard in Windows can theoretically generate more than one codepoint per character for certain very rarely used characters. For instance the MUSICAL SYMBOL G CLEF is outside of the 16-bit code range that UTF-16 can represent in a single codepoint. So if you want to preserve possible input strings beyond an embedded NULL character, things get fairly hairy when using the Windows conversion function as you would have to call it repeatedly on each individual text section that is separated by a NULL character. But trying to build your own conversion routine is an even worse idea. Nobody in his sane mind wants to do encoding translations themselves. 😀

Edited February 13, 2022 by Rolf Kalbermatter