LV 2021 automatically fills indicator

[MaSta]

---

@NIquist wrote:

I agree with RTSLVU.  I can't think of any default behavior that would be more convenient and expected than what it currently is.  Whether a constant, control or indicator; they all act just like you cut and pasted or cntl drag and dropped them.  If they have content, it is copied.  If they don't, it's blank.  Sounds right to me.  🤔

---

Different people have different thoughts. My logic tells me, the indicator should go blank again once I cut the wire, but it won't. So that default behavior is illogical to me when the code is just typed.

[billko]

---

@MaSta wrote:

---

@NIquist wrote:

I agree with RTSLVU.  I can't think of any default behavior that would be more convenient and expected than what it currently is.  Whether a constant, control or indicator; they all act just like you cut and pasted or cntl drag and dropped them.  If they have content, it is copied.  If they don't, it's blank.  Sounds right to me.  🤔

---

Different people have different thoughts. My logic tells me, the indicator should go blank again once I cut the wire, but it won't. So that default behavior is illogical to me when the code is just typed.

---

For me, sometimes it helps, sometimes it hinders.  More often than not, I don't even pay attention to it.  Possibly because I rarely create indicators from constants or constants from controls.

[altenbach]

So this really has nothing to do with the wiring, but with switching an item between constant|control|indicator.

A diagram constant values is always the "default value" and if I want a control with a certain default value, creating a constant, filling a value, and switching it to be a control is often faster than creating the control, filling the value, and setting the default. This behavior has always been desired. Similarly, e.g. during debugging, I create an indicator after the file reading, run once, then turn the indicator into a constant and disable the file IO. This makes testing faster. Or I might run known good code and create a constant from the final result, then do a comparison with the new value after some code tweaks to ensure that the result is still as expected.

More annoying to me is that if I have a constant and I need an array of constants (e.g. strings), I get an array of strings where the elements have the default value of the original constant. In most cases, my muscle memory automatically clears the contents of constants before turning it into an array. It is annoying if all elements outside the valid range have a greyed out non-empty string value.

[NIquist]

---

@billko wrote:

---

---

For me, sometimes it helps, sometimes it hinders.  More often than not, I don't even pay attention to it.  Possibly because I rarely create indicators from constants or constants from controls.

---

Agreed, I may play around at first when I design my GUI and then I like the quick "Change to.." behavior.  When I go to make my final GUI, I will start all over and make it pretty by starting with new indicators.  Put them in decorations, tabs or whatever and align them nicely.  The current behavior seems like a reasonable compromise.

I noticed that C# (WPF at least) has similar behavior.  You can't "Change to ...".  But if you copy/paste a TextBlock, its content gets copied too.

[santo_13]

---

@altenbach wrote:

So this really has nothing to do with the wiring, but with switching an item between constant|control|indicator.

A diagram constant values is always the "default value" and if I want a control with a certain default value, creating a constant, filling a value, and switching it to be a control is often faster than creating the control, filling the value, and setting the default. This behavior has always been desired. Similarly, e.g. during debugging, I create an indicator after the file reading, run once, then turn the indicator into a constant and disable the file IO. This makes testing faster. Or I might run known good code and create a constant from the final result, then do a comparison with the new value after some code tweaks to ensure that the result is still as expected.

More annoying to me is that if I have a constant and I need an array of constants (e.g. strings), I get an array of strings where the elements have the default value of the original constant. In most cases, my muscle memory automatically clears the contents of constants before turning it into an array. It is annoying if all elements outside the valid range have a greyed out non-empty string value.

---

I have exploited this feature a lot during debugging, I get a copy of runtime data of some wire for offline testing, in this case, I would probe the data, copy it to a VI as a constant and create controls/indicators from them, now I can create tests with a default value for the inputs.