10-21-2013 06:46 PM
Fact: When I select a Text Ring on the FP and use Edit>>Make Current Values Default, Save the VI and after changing the Ring value, select Edit>> Reinitialize Values to Default (or right-clicking the ring itself, choosing Data operations>> Reinitialize to Default Value, nothing happens.
In other words, it appears as if LV was ignoring the Default Value of a Text Ring. Or since it is a numeric, not understanding that the array of strings should ALSO be saved with the index in that array (since the numeric is just that, an index for an array of strings.
Simple question: Is this a well-documented feature, because it does not make any sense, and hence I suggest this is a bug.
Temporarily testing this on LV 2011 32 bits.
10-21-2013 07:37 PM
I was pretty certain you were smoking something, but then I created a new system ring in LV12 and saw what you were talking about. I tried again with a modern ring and it worked as expected. Same for classic and silver. And then, when I went back to the system control it worked normally as well. Weird.
10-22-2013 11:47 AM
Weird, I was smoking something, how did you guess?
I was actually using a Silver style Ring. I just tested in on LV 2013 f1, with a Silver style Text Ring and it did fail to reset to the default string(s) (I only entered 1 string initially, but it works the same with more strings entered in the ring). It does reset the VALUE of the text ring correctly, but that is not enough!
I want my strings back!!!
CAR #?????
10-22-2013 12:07 PM
I see, I was sidetracked by the intermittent failure of my rings to even reset the value to the default.
Strings are neither type (int32 say) nor value (0,1,2), they are part of the appearance like the color. If you change the color, it ain't coming back when you reset to default values.
The entire ring/enum implementation is a bit of a steaming mess at the moment. Enums are a bit too static, rings are a bit too dynamic. There is this hole in the middle where people want the strings to be a bit more value-like. This typically leads to abuse of either a ring or enum.
It sounds like you have dynamic strings in your rings so the thing to do is write the strings to the rings in the beginning.
10-22-2013 01:25 PM
Another case of "no strings attached" false advertisement?
I could not find any warning in the Help that all edit work would be lost when "Set Current Value as Default" for a Text Ring (or even worse, for a Picture Ring).
You cannot pretend that the fact a Picture Ring Control DOES NOT SAVE THE PICTURES with the "Set Current Value as Default" action IS AN EXPECTED BEHAVIOR.
It might be intended (because it is easier to program?) but it certainly is not expected.
Unlesss of course you are one of those "Knights of NI"(*) who will accept anything coming from Austin...
(*) Can't post a YouTube link in the forum, but Google "Monthy Python Knights of NI" to the same effect.
10-22-2013 01:34 PM - edited 10-22-2013 01:35 PM
Text Ring control Text.text property isn't on of those properties that is inviolate between instances of a definition of type Text Ring.
Granted, if you know this consider yourself a shoe-in to be a LabVIEW Trivia contest honerable mention. (Allways something else to learn)
It really is the way they've always worked. Now, if you ask "Would I sometimes prefer another object that behaves differently?" I'd have to say yes.
10-22-2013 01:43 PM
> You cannot pretend that the fact a Picture Ring Control DOES NOT SAVE THE PICTURES with the "Set Current Value as Default" action IS AN EXPECTED BEHAVIOR.
I do not pretend that that is expected or actual behavior. The pictures are saved as part of the control when you add them. There is no way to dynamically add/remove/rearrange the pictures. The only way to lose the pictures is to not save the VI, which would also lose your changes to the default value. What am I missing here?
10-22-2013 02:48 PM
That was a generic "you", nothing personal.
Regarding the Pic ring, if you save the VI after defining the ring content and setting the Default value.
Then modify the ring (say delete a picture, or replace one), using "Reset to Default" wont get the previous pic back.
Am I missing something?
10-22-2013 05:25 PM
X. wrote:Am I missing something?
Most characteristics are saved with the VI (and can be Reverted or Undone if desired). Values are treated differently; you have to explicitly set the "default value", which is saved, but the plain value is not otherwise saved. This is because values are expected to change at run time, while other control characteristics usually do not. An advantage of this is that you do get a "Reinitialize to Default Value".
10-22-2013 05:42 PM
Is this a behavior (the one I described as "expected") that might fly in the Idea Exchange, or is there some philosophical dogma preventing this to be even considered?