Mysterious string color bug

[lavalava]

My Labview version: 8.6 Developer

Issue:  I run into a mysterious problem when coloring the string indicator, the indicator will always reset the color to the first character instead of retaining the settings that I told it to retained. Consequently, you'll get a lot of red blinks if you take out the time delay.  I added time delay to make this problem more obviously.  It's probably much easier if you guys take a look at my code.   Is there a solution to this problem?  I found someone's post 5 years ago but no solution. Please don't suggest using a picture control because I want my end user to copy and paste.

---

---

[Darin.K]

This has bugged me on a few non-consecutive occasions.  My quick fix as described here:

http://forums.ni.com/t5/LabVIEW/programming-string-value-destroys-format/m-p/1087197#M481086

is to borrow from the Bold Particular String.vi in vi.lib and use <color></color> tags to color text.  Here is that example converted to LV8.6.

[altenbach]

You could just defer panel updates while changing the string and updating the colors.

[lavalava]

Thanks for trying, guys.  Both solutions are still causing the string indicator to blink.  Labview still takes the color of the first character, then repaint the entire string indicator right before the color setting loop based on that single color, which means you'll see a lot of migrance blinkings.  It shouldn't do that at all.  This is driving me crazy.  I want it to stop doing that.

[altenbach]

I don't see any "blinking" in my solution, even if I remove the wait in the outer loop. What did you modify?

Make sure that writing to the control takes place while front panel updates are deferred (I am using a value property node to force execution order via the error wire).

I would also recommend a format with a fixed number of decimal positions on the last line, e.g. "%.05f"

[altenbach]

---

altenbach wrote:

Make sure that writing to the control takes place while front panel updates are deferred (I am using a value property node to force execution order via the error wire).

---

Even if you want to write directly to the string terminal, you still need to make sure it happens while updates are deferred, e.g. as follows using a sequence frame.

[lavalava]

It blinks even more as you run multiple VI at the same time.  Try this, you have two defers: the first one is true, the second is false.  Put a break point on the second defer.  Run it, when it pauses at the break point  you'll see labview resets everything to red.   This is the problem, it blinks.  You'll see the red flashing over the black very quickly.  The problem doesn't exist if there is no change in text, but as long as you are changing the text without regard to length ...it's just going to blink regardless of your fixed float.

I like your idea, I think it's a good idea but when labview gets to the second defer, it's still resetting all the color to the color of the first character.

[Darin.K]

I don't see blinking with ABs example deferring updates, but I certainly have found other situations where I could not avoid the redraw and some blinking.  CPU load could be a factor, although this machine is pretty darn sluggish.

Side note about the example:

Maybe there is a use case for #3 that I am missing and I'll learn something new...

[lavalava]

Sorry but your solution also blink too.  Here do this, take your run example file.  Create a string with a constant changing text such as this one:

<green>This is green</green> <black>this is black</black> <green> RG: {fill this part with a random number from the random number generator}</green>

ok, loop the whole thing with a 1s ticker and you'll see it blinks every cycle.

[altenbach]

---

@lavalava wrote:

This is the problem, it blinks.

---

I only tested in LabVIEWQ 2010, where it definitely does not blink. Maybe 8.6 has a subtle issue, but I cannot verify.

Darin, I don't use it enough to worry, just some quick rube because I could not find the correct property (looking for "panel" instead of "front panel"). Your method for the panel reference is definitely better and I think that's what I actually use in my code elsewhere. 😄