Signed Text Ring bug

[Ettepet]

Using the latest version Labview (LV2013) I build a "Text Ring" based on a signed integer (I8).  I filled the whole table (256 items) with a dedicated string starting at 0..127, followed by -128..-1.  Along the way I encountered several related problems / bugs.  The "StringAndValues[]" property is correct, but for anything else Labview has decided that after the first (positive) half of the table the remaining values must obviously all be rounded to 127.  Effectively, in most ways the second halve I entered (-128..-1) does not exist.

2 questions:

   1. Can I circumvent this "phenomenon" by ordering the table from -128..127, or some other way ?

   2. If so, is there a quick way to convert my current table ?

[Dennis_Knutson]

I cannot reproduce this with 2013. Please attach your VI.

[JÞB]

Some quick playing around-  This seams to be an artifact of the item editor.  You can't add negative values unless you check "Allow undefined items" if you use same the property browser session to change representation.

The obvious workaround is to set representation before editing items

[Ettepet]

---

@JÞB wrote:

Some quick playing around-  This seams to be an artifact of the item editor.  You can't add negative values unless you check "Allow undefined items" if you use same the property browser session to change representation.

The obvious workaround is to set representation before editing items

---

One of the manifestations of the bug I encountered is that I had to make it a 16-bit signed integer (I16) before it accepted the 128 negative assignments.  At least it did so in the order that I entered them in the Text Ring table (0..127 first).

I think internally several bugs exist, all possibly related to the artificial "Sequential values" flag, seeing I entered ALL items from 0..127 in order.

I will post an example on monday if necessary.

[GerdW]

Hi Ettepet,

just for curiosity: what is the reason to create a text ring with 256 items? (It will be a UI nightmare...)

[Darin.K]

---

@GerdW wrote:

Hi Ettepet,

just for curiosity: what is the reason to create a text ring with 256 items? (It will be a UI nightmare...)

---

For input I agree with GerdW, as an output I disagree.

Either way, for me the nightmare is populating said text ring via the editor instead of programmatically.

[JÞB]

---

@Darin.K wrote:

Either way, for me the nightmare is populating said text ring via the editor instead of programmatically.

---

Where have we heard this before.  http://forums.ni.com/t5/forums/searchpage/tab/message?location=idea-board%3Alabviewideas&q=Items+edi...

[Ettepet]

---

@Darin.K wrote:

---

@GerdW wrote:

Hi Ettepet,

just for curiosity: what is the reason to create a text ring with 256 items? (It will be a UI nightmare...)

---

For input I agree with GerdW, as an output I disagree.

Either way, for me the nightmare is populating said text ring via the editor instead of programmatically.

---

I use it for both.  90% is just filled with the index value (+ unit), but a few values are special.  I used to have a table in a tip strip, but I found this solution to be more user friendly.

Well, I finally solved the problem by re-entering the table in the regular order (-128..127).  This really should be default for signed integers when using the "Sequential values" option.  It would have saved me a lot of re-typing, as what it currently does is 0..127 only.  With all the legacy issues it could cause I would just look at the first entered value when someone enables the "Sequential values" flag and number the rest from there on.

Seeing all the typing I have done today I feel little incentive to "prove the issue" by posting an example.  But I would safely bet that after entering values (+ text) for 0..127 and then trying to add anything else (-128 for instance) you will see the issues I was having.