03-31-2025 10:47 AM
@billko wrote:
@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".
Oh wow.... your right!
03-31-2025 11:09 AM
It doesn't, though if you're looking at what I wrote please note that I also mentioned removing all non-printable characters as a standard. A null does not pass that check.
The "printable" check actually also removes tabs, newlines, and carriage returns. In nearly all cases I don't expect or want those in the strings I get as inputs, since mostly what I get as inputs are things like serial numbers or product numbers, which might have letters or punctuation but never a tab.
08-11-2025 08:12 AM - edited 08-11-2025 08:24 AM
Weird facts about this behavior:
1... If you select the text and DRAG it from Word to the string control, you don't get the NULL
2... If you have TWO LINES in WORD, and select EITHER ONE of them to copy/paste, you get the NULL, but if you select BOTH, you don't.
3... The NULL is always at the end.
I don't see a better way than:
Intercepting a KEY DOWN? event on the destination control(s).
If the SCAN CODE == 29 (control-V), then:
Use an INVOKE NODE - CLIPBOARD - READ FROM CLIPBOARD method
Remove a possible null at the end.
Use an INVOKE NODE - CLIPBOARD - WRITE TO CLIPBOARD method
proceed with event.
--- That changes the actual clipboard, though.
--- It doesn't address PASTE from a MENU.
--- The program has to be running at the time of PASTE.
Open to better ideas...
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-11-2025 01:31 PM
In testing the fix for this, I discovered another anomaly:
If I have the text "3.1415926535" in WORD and copy it, I can't paste it into a LabVIEW numeric control. Nothing happens. It's not the NULL character problem, it just ignores it.
I can copy from CALCULATOR, I can copy from NOTEPAD++, I can copy from NOTEPAD. But not WORD Enterprise
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-14-2025 07:37 PM - edited 08-14-2025 07:42 PM
only tab, linefeed, carriage return and space are removed based on BD
08-14-2025 07:39 PM - edited 08-14-2025 07:49 PM
you can always try to open the front panel and show the block diagram to understand the codes (especially with the broken documentation), not all the vis are password-protected. just be careful to NOT save when closing or you may introduce changes into your tool chain and break future codes