Showing results for 
Search instead for 
Did you mean: 

hex string display bug LabVIEW 2009 SP1

I think I discovered a minor string indicator display bug.


I was trying to write a vi that compared data downloaded from a micro with master data in a file.

When a mismatch is found the bytes that don't match are highlighted in red.


If you change the font color of two odd bytes next to each other it messes up the display.


Normally, when a string is displayed as hex, the bytes are grouped in twos. E.g. 1122  3344  5566

If you change the font color of two bytes not grouped together, they group!    E.g. 1122  3344  5566 becomes 112233  4455  66


Steps to reproduce:

1. In a string indicator set to display as hex, highlight 2 bytes that aren't grouped next to each other.

2. Select 'color' from the font dropdown menu and select a color.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Message 1 of 9




Verified behavior on LV2009SP1 on Win7 and LV 8.6.1 on XP.










0 Kudos
Message 2 of 9

Behavior still occurs on LV 2010. Ray has filed this in the monthly bug thread.

0 Kudos
Message 3 of 9

Thank you for brining this issue to our attention. I have gone ahead and reported this to R&D in CAR 250641. Thanks for the feedback!


Stephanie A.
Americas Marketing Manager
National Instruments
0 Kudos
Message 4 of 9

Really a hard to find bug: verified with LV 6.1 !!!

My compliments to the finder! Smiley Very Happy


LV 7.1, 2011, 2017, 2019
0 Kudos
Message 5 of 9

Any chance this will get fixed ever?


This seems to be an issue still.


I'm also writing some VIs that manipulate data, so I was using some colors to mask information.



0 Kudos
Message 6 of 9

I can confirm that I still see the bug 10 years later in LabVIEW 2019.


I guess this is too low a priority?

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 7 of 9

@TroyK wrote:

I guess this is too low a priority?

From insights I have been able to gleam, NI only really goes after non-major bugs when that section of code is due to be worked on for new features or refactoring.  Have there really been any updates to string controls over that long of time?  Not that I can think of.  And there is also the "how many people would actually see this?" which could lower the priority.

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 9

So text displays in LV have two components, the data and the style information.  The style information for a display is stored in a series of 'runs'.  Each run has a start position and a length.  The added spaces are treated (appropriately) as part of the style, unfortunately, the way it is implemented is that the spaces are added after every two bytes within a given run, you see the results when a new run is started at an odd location.


My suggestion is use a hidden string control set to hex display to receive the data.  Use the Text.Text property to get the hex string (spaces included) to display in a separate indicator set to normal display.  Now you can use the Text.Selection properties along with Font.Color to highlight this string.  With the included spaces, just remember that index += index << 2 (ie. index = index + index/4)





You can easily change the math to index by bytes instead of using the raw location like this example.  Remember that the stop location is not inclusive as well.

Message 9 of 9