[LabVIEW Feature Report] "Find text" fails to identify string constants using a non default display style

[X.]

I had been wondering for a while why I could not locate the strings I was seeing in some of my pop-up dialog windows by simply searching for them.

I now know why.

If you set the Display Style of a string constant to anything but the default "Normal Display" style, say, if you choose "'\' Codes Display", you have to search for the string as shown in that style to get a hit.

Let me illustrate this.

Say I have this string constant in one of my BDs: The Min Size parameter can't be equal to zero: set to 1 ns

but for whatever reason, I decide to display it using the "'\' Codes Display" style so that I can check whether I have tabs or EOL in it (and how many):

If I pass this string to a One Button Dialog function, the display will look like so:

If I wan't to go to the VI that generates this dialog, my only option is to type in the string show above (or part of it) and search for it.

Unfortunately, since the string constant uses the "'\' Codes Display" style, these are two different strings for the search tool, and the string is not found.

If I use the string: The\sMin\sSize\sparameter\scan't\sbe\sequal\sto\szero:\sset\sto\s1 however, the string constant will be found.

To some extent, this is an expected outcome. After all, the same string constant displayed using the "Hex Display" style would look like: 5468 6520 4D69 6E20 5369 7A65 2070 6172 616D 6574 6572 2063 616E 2774 2062 6520 6571 7561 6C20 746F 207A 6572 6F3A 2073 6574 2074 6F20 3120 6E73 0A

This definitely looks different from the string shown in the dialog box above. Yet the dialog box would display the exact same string as shown in the snapshot above.

I could repeat this argument with the "Password Display" style.

In other words, searching for string constants is a trivial matter only for constants shown in "Normal Display" style, but can be highly non trivial if the constant uses a different style.

If this is an intended behavior, I would suggest providing an option to ignore Display Style during the search (maybe with the exception of the Passord Display style, for obvious reasons).

Comments?

Tested in LV 2016 64 bits on Windows 7

[mikeporter]

Expected behavior. The idea of the find is to locate the string as it appears in the code.

How many assumptions do you want LabVIEW to make for you?

Mike...

[Henrik_Volkers]

---

@mikeporter wrote:
How many assumptions do you want LabVIEW to make for you?

---

Why the dynamic data type came into my mind ?

[natasftw]

I'd guess this is expected.  It's likely comparing the strings literally.  As they look different, it throws a false. 

I wouldn't be opposed to the functionality being changed to compare the hex strings against each other (as the hex for each should be identical) so you'd be able to find strings regardless of display type.  I don't know there's a need for a password exception for two reasons:

1) if you're searching for the password, you already know it.

2) if you have access to the source code, you can already change the display type and have the password displayed anyway.

To be fair, that's not the "only" way to find where that takes place in your code.  You did something to bring that up.  It wouldn't be difficult to start the code, turn on highlight execution, hit whatever made that pop up, and follow the code to see where it comes up.  There's a decent chance you can double-click the control during edit time and have it take you to the terminal on the block diagram to see what's taking place as well.

---

[X.]

Try this piece of code:

The result is:

Ergo, as far as LV is concerned, these strings are identical.

I understand that a "text seach" is in principle a different thing, so I tried the following:

1. Select the content of the "\ Code Display" string above and paste it in the Search box.

2. Run the search in the VI above. You will be interested to find out that there are two hits:

The first one is:

The second is:

So now we have entered the rabbit's hole.

The '\' Codes Display string is NOT found but the plain text style one is actually found!

Clearly the developers had some very precise intent in coding the Search for text tool. Too bad they did not share their intent with us users...

[X.]

CAR #603609 has been filed for this issue.