03-27-2025 03:11 PM
I had a weird bug show up recently. I have a program where the user can type in the name of a few tests, then those tests get exported to TDMS. This has worked fine for a long time, until she wound up copying the name of a test from Word, pasting it into LabVIEW, adding a couple characters (e.g., "run 1"), then saving it.
Somehow, the data was getting combined into one entry into the TDMS file, with none of the appended data in the section name.
The problem is that, for some reason, copying from Word is appending a null character to the string:
So, I can handle this on the paste end by filtering the string for nulls, but... is there a more general solution to this? I have a LOT of fields that could be copy/pasted, and it's a huge annoyance to have to check for nulls in every single one. This seems to be a problem only for LabVIEW, since every other text editor I found would stop the paste at the null character.
03-27-2025 08:17 PM
Dunno. I just tried it with Word and LabVIEW and didn't see this problem. I'm running Microsoft Office Home and Business 2021, and tried with LabVIEW 2019. I did see (while selecting a Word short sentence) what appeared to be an extra "blank space" at the right end, but when pasted into a String Control, no obvious space was present, and when this Control was wired to a "String to Byte Array" and it ended in the Ascii values of the last two characters, no trailing 00.
You've got a Gremlin!
Bob Schor
03-28-2025 03:30 AM
It generally works fine, but LabVIEW version might be highly relevant. I seem to remember that there was at some point a bug when copy-pasting text strings from the clipboard into controls and/or using the Read from Clipboard VI server method.
The fix might be simply a newer bugfix install for the users LabVIEW runtime or maybe an upgrade to a newer LabVIEW version.altogether.
03-28-2025 07:10 AM
I tried to reproduce this, but I can't using Ms 365 word desktop and labview 2020
maybe this is a rare usecase for MS PowerToy's advanced paste....
but I guess, this is more likely a setting in your MS word? use microsofts copilot to help you solve your issue 😉 ...
03-28-2025 07:17 AM
I had this recently, never seen before. I think maybe switching from win 10 to win 11, it the new notepad maybe. I had to add a fix to strip the /00 because the whitespace was causing errors in JsonText. I could not see exactly what causes the /00 but it does not always happen
03-28-2025 09:55 AM
@rolfk wrote:
It generally works fine, but LabVIEW version might be highly relevant. I seem to remember that there was at some point a bug when copy-pasting text strings from the clipboard into controls and/or using the Read from Clipboard VI server method.
The fix might be simply a newer bugfix install for the users LabVIEW runtime or maybe an upgrade to a newer LabVIEW version.altogether.
There was something similar with a path control.
https://lavag.org/topic/22466-labview-2021-sp1-known-issues/
03-28-2025 10:39 AM
Dang, thanks for all the reproduction tests everyone!
FWIW, I'm on Windows 11, LV2023 Q3 64-bit, and "Microsoft 365 Apps for Enterprise" (a standalone install, not the browser version). This happens on my dev environment and on the installed executable. The copy paste was from the clipboard (as seen in the video). I haven't tried it yet with VI Server methods.
03-28-2025 02:26 PM - edited 03-28-2025 02:28 PM
I think you get the null because you highlighted the entire row in Word instead of just the text 'Test unit 15'. Happens when you want all the text in single row and Word will extend the selected part to include the null. You can see extra null chars (tabs, indexes, etc) by enabling them. If you just select the text and paste it onto LV then it'll be ok.
03-28-2025 03:16 PM
I've had so many problems with text inputs from users being weird that I run pretty much every text field input through a sanitizer. The standard one I use trims whitespace from both ends, removes any non-printable characters, and if there's ever two or more spaces in a row in the middle it trims them down to just one space.
Add in a case-insensitive equals check and the whole thing makes all string operations a lot smoother when they have to deal with strings from any sort of external input.
There can be exceptions, like places where monospaced fonts are used and exact space counts actually are useful, but those are the exception rather than the general rule.
03-29-2025 01:24 AM
@Kyle97330 wrote:
I've had so many problems with text inputs from users being weird that I run pretty much every text field input through a sanitizer. The standard one I use trims whitespace from both ends, removes any non-printable characters, and if there's ever two or more spaces in a row in the middle it trims them down to just one space.
Add in a case-insensitive equals check and the whole thing makes all string operations a lot smoother when they have to deal with strings from any sort of external input.
There can be exceptions, like places where monospaced fonts are used and exact space counts actually are useful, but those are the exception rather than the general rule.
I don't think a null counts as "whitespace".