Get type info in malleable VI returns VIM input control name. Bug?

[thols]

If "Get Type information.vi" is used in a standard VI and used as a sub VI, I will get the name of the control of the main VI correctly, but if I do the same in a malleable VI, I get the name of the control label of the malleable VI input.

Code attached. See result:

Using LV2021. Is this an introduced bug in later versions? Or is this expected? 

[wiebe@CARYA]

---

@thols wrote:

Using LV2021. Is this an introduced bug in later versions? Or is this expected? 

---

It's expected, and by design. It won't change.

Malleable control labels - Page 6 - NI Community

[paul_cardinale · Accepted solution]

Here's what's happening:

Notice the coercion dot at the input to the call of "Get type info sub VI.vi".  That coercion dot takes the data and converts it to a variant; this coercion takes place outside of the SubVI.  Thus the name of the data that gets embedded in the variant is taken from the calling VI.

However, since the input of "Get type info sub VIM.vim" is already a variant, no coercion takes place..  So the name of the data is the name of the (vim's) control.  If you convert the data to a variant before calling the .vim, you'll get the result you want:

[thols]

---

wiebe@CARYA wrote:

---

@thols wrote:

Using LV2021. Is this an introduced bug in later versions? Or is this expected? 

---

It's expected, and by design. It won't change.

Malleable control labels - Page 6 - NI Community

---

Thanks for that link. Had missed that. Interesting discussion.

Thanks paul_cardinale for the solution. I was so certain that this had worked before, and it did... if I converted to Variant first. Forgot that.

[wiebe@CARYA]

---

@thols wrote:

---

wiebe@CARYA wrote:

---

@thols wrote:

Using LV2021. Is this an introduced bug in later versions? Or is this expected? 

---

It's expected, and by design. It won't change.

Malleable control labels - Page 6 - NI Community

---

Thanks for that link. Had missed that. Interesting discussion.

Thanks paul_cardinale for the solution. I was so certain that this had worked before, and it did... if I converted to Variant first. Forgot that.

---

Of course if you convert to variant before the VI, you often loose the reason to use a .vim. 🤔

If you don't use a .vim anymore, the input can be a variant and you don't need to convert before the VI. 

I still think it would add value if .vim inputs adapt their control names to the wire. But it's just not likely to happen.

As it is, you need to choose between 100% variants (sloooow) if you want wire labels or .vim (fast, but no wire labels).

[thols]

---

wiebe@CARYA wrote:
Of course if you convert to variant before the VI, you often loose the reason to use a .vim.

 If you don't use a .vim anymore, the input can be a variant and you don't need to convert before the VI. 

I still think it would add value if .vim inputs adapt their control names to the wire. But it's just not likely to happen.

As it is, you need to choose between 100% variants (sloooow) if you want wire labels or .vim (fast, but no wire labels).

---

My vim did a couple of other things but I will probably go for a variant. I want simplicity and don't require speed. But the discussion of how NXG was to implement it makes me wonder if it perhaps isn't such a good idea to just let the variant input just pick up and use the name from wherever it go set on the wire. Well, for me it works, but it might not be so visible for a user what happens and not so understandable that the name will be pulled from the input wire. Next time I might go for another design.

[wiebe@CARYA]

I agree that using wire labels can make code a bit shady.

They are convenient though. Variant labels are pretty consistent as well. For instance a variant in a value change event gets the label of the control that signaled the change. A reference gives this information as well, but if you need to go 'variant' anyway, having the label in it saves code and performance.