hex string display bug LabVIEW 2009 SP1

[TroyK]

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.

[Wayne.C]

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

[smercurio_fc]

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

[StephanieA]

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!

[pincpanter]

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

My compliments to the finder!

[HD_Studio]

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.

[TroyK]

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

I guess this is too low a priority?

[crossrulz]

---

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

[Darin.K]

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.