String indicator - Text.Selection and Text.Font strange behavior, bug?

[Blokk]

I have attached a VI, see also the snippet for easy recreation. Behavior tested in LV2017 SP1.

Steps to reproduce behavior:

1. Open the VI (or get it from the snippet) from local disk where it was saved before
2. Run it, it works as expected: the font style of the first line is changed, the rest stays the same
3. Do any small modification on the VI, like change the size of the string indicator a little bit, or just type some text on the FP as free label, etc...
4. Close the VI, and select "save" when asked
5. Open the VI again, and run it again.
6. Now the whole text gets bold and red in the indicator! Why?? Intended behavior??

What is interesting, is that, if you modify lets say the last line of the string to bold and red font (and not the first few characters of the whole string), you do not get this behavior...

Recently I use a workaround to avoid problems caused by this behavior, that I select the whole string first, and set it to non-bold and black, then I change the required part to bold-red only...

EDIT: If you manually delete the text from the indicator, BEFORE Step 4., you do not get this "bug". It looks like the indicator "inherits" the style from the first characters being present in it (when you save the VI after any small modification), even if the Default Value of this indicator is an empty string... Maybe this is the intended behavior???

[Blokk]

I made a small example project (zip attached in LV2017), just to recreate some strange behavior I see when use this Text font changes on a string indicator, being in a subVI, displayed in a SubPanel. I do not know if this "bug" has anything to do with the usage of SubPanel, but I see this problem in my actual project, so created a small mockup. So just to show, there is no need to do any changes / save changes on the subVI, to get inconsistent behavior. Here I had several things which could cause the change of the text-style, for example if the user clicks into the indicator, at some location of the text. Stopping and rerunning the VI (no need for changes/saving), will result in changing the text style up to the point where the mouse was click in...strange! 🙂

Anyway, of course a built executable does not show this behavior, but we need to be careful to save the VIs with these string indicators setting up as black and non-bold fonts, before building the EXE...

So these kind of strange things are only present when I work in the IDE on my projects...

I made a short video to show what happens in my case when using the VI in a SubPanel:

https://youtu.be/EcqjzC1LMs8

[cstorey]

Change the order which you set the Text.SelEnd and Text.SelStart in your Property Node.  Start first then End second rather than End then Start as you had.  This seems to work as you desire for me no matter where the cursor is placed at then end of previous run. 

It seems like the Text.SelEnd is using the cursor position rather than what you tell it the way you specify the End first.  Not sure if this is desireable behaviour, but maybe due to the need to select a start point before you can Select anything?

[Blokk]

---

@cstorey wrote:

Change the order which you set the Text.SelEnd and Text.SelStart in your Property Node.  Start first then End second rather than End then Start as you had.  This seems to work as you desire for me no matter where the cursor is placed at then end of previous run. 

It seems like the Text.SelEnd is using the cursor position rather than what you tell it the way you specify the End first.  Not sure if this is desireable behaviour, but maybe due to the need to select a start point before you can Select anything!

---

Thanks! Yes, swapping the order of the end/start to start/end fixed this particular problem, aka clicking into the lines with the mouse (and clicking away after) will change the selection somehow... I do not know still if this is a bug, but in any way, the default order should be swapped in the property node list (should start with "start"):

Besides, changing the order of the "end" and "start" elements do not fix the other problem: just run the VI, then close it (no need to modify anything I just realized, so no need to save it, no "save" prompt!). After reopening, run it again. The whole text will turn into red/bold...

Edit: no, I just tricked myself: so you need indeed to modify something on the VI, to get the "everything turned into bold" problem. So you need to perform a save action on the VI, close it, reopen it, then run it...this case, the problem still exists even with the correct "end/start" element order...

[Bob_Schor]

Wow, Blokk -- you find the weirdest bugs!  I just tested this with LabVIEW 2016 (I'm leery of 2017, which has cost me weeks of down time trying to fix my PCs), and verified that it fails there as well.  I simplified things a bit, but the general idea is the same.  Here's my Snippet:

Rather than use a Sequence, I used the same set of properties used in the Fix.  I also used the Cluster for Text Selection which is ordered Start, End.

I also found that all you have to do to make the bug appear is to run a Saved VI.  I did the following:

1. Run code.  Whether or not bug appears, run with Fix True, then run with Fix False.  Note proper behavior.
2. Type Ctrl-S (to Save), close FP without making any changes.
3. Run again.  Bug appears (all three lines Red and Bold).

I tried a few extra tricks, like having separate Property nodes for Selection and Font Style and Color -- still weird.

Bottom line -- don't do that!

Bob Schor