5 replies to this topic

[François Normandin]

Following up on this question,

I've been wondering if this behavior is a bug or an intended feature and would like your opinion.
Personaly I think it's a bug... but I might be biased by the end result I'm trying to reach.

The issue is that when one uses String.TextSelction.Start and End properties to change the font of a string subset, it works as one should expect. But as soon as you append a string to it, the whole string text reverts to the font of the last property set instead of just adding the text at the end and keeping the fonts for the rest of the string. To better understand, try out the VI below. I've deliberately added a delay to allow for more dramatic effect...

I can see why this "bug", if it is one, would be tough to get rid of. It has implications in how a string constant/control/indicator works. For example, if the font color from index 7 to 14 is "blue" and I insert a string subset at index 10, then it should follow that the text I insert would be "blue" also.

The current workaround is to read the fonts of all characters in the string before appending/inserting and to rewrite each fonts after the operation, to restore the colored lines. It is nice when working on short strings, but imagine a log system with hundreds if not thousands of lines, all different colors for informations, alarms, data, etc. Even with panel update differing, it would be time-consuming...

 Change line color LV85.vi   11.77K   339 downloads
 Change line color LV86.vi   10.93K   325 downloads

[gleichman]

I saw the same results when running your example. It appears to be a bug to me, but like Omar said in your last thread, maybe this is the wrong tool for the job. Have you tried using an MCL or table?

[François Normandin]

I saw the same results when running your example. It appears to be a bug to me, but like Omar said in your last thread, maybe this is the wrong tool for the job. Have you tried using an MCL or table?

Indeed, I have been using MCL. But in the past I have also written code where I want the user to write a script that I will have an engine to execute automatically. Now, an MCL can do that too, specifically with a good use of drag n' drop from a list of commands, but it is easier in a text string to let the user edit parameters without double-clicking and opening yet another pop-up. In such a case, I would have wanted to parse the string and color it the way a Python editor would (for example). It's not optimal to have to rewrite the whole string font scheme everytime you drop a new command.

[crelf]

I wanted to bump this thread, as I'm having the same issue right now. Please vote!

[silmaril]

I wanted to bump this thread, as I'm having the same issue right now. Please vote!

I'm the one who voted "intendet behaviour" (it's only one right now).
Let me explain, why I don't think this is a bug:

We are talking about a simple string control.
There is no method to append data to the end of the string.
If there was such a method, I would agree, that the formatting of the existing text should not be changed when something is appended.
But this is not what we are doing here.
In this example we are reading the value from the control (which is the complete string without any formatting, because strings don't carry this kind of information).
After this, another string is appended (still without any format info).
This new string is written back to the control (did I mention it doesn't carry any format info?).
From the control's point of view, this new string has nothing to do with it's current value.
So in most cases the old formatting instructions (based on character indices) will be outright wrong.
I think setting all characters to a common format is the only sensible thing to do here.

What you are talking about here is a special case.
I can see clearly, why you would like to have a simple way to keep your format definitions, but I don't think this should work automatically when setting the complete control value.
The next thing would be to check if the beginning of the new string is identical to the old string... In most cases this would just use lots of CPU without a benefit.

Instead I would suggest introducing an additional string control method "Insert String". This would have a string input as well as an index input. The new string would be inserted into the current string at the specified position. All "old" characters would keep their format (both before and after the inserted string). The new part would take it's format from the character after which is was inserted.
The index input should be optional with a default value of -1, meaning the string is appended to the end.

[ShaunR]

I'd like to see a native "HTML" string control