Jump to content

String copy strangeness


Recommended Posts

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).

Link to comment
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 

Link to comment

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.

Link to comment
  • 5 weeks later...

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 by Rolf Kalbermatter
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.