How is it possible an Inline sub VI can contain something not inlined

[danny_t]

I have been playing with Malleable VI's lately and have been struck by the fact that there is a workaround to creating a VIM that affects a property node, the workaround is needed as you cannot inline subVI's that contain a property node.

The workaround is to place the property node action within a subVI that is NOT inline and place that subVI in your inlined VIM. This works fine I have tried it out and it has been talked about in a number of places as something you can do.

The workaround, which is great and very useful, just feels wrong and something that should not be possible. I thought that when a subVI was inlined, the block diagram of the inlined VI was placed at compile time onto the block diagram of the calling VI. but for that to be true surely all inlined VIs needed to hierarchically contain only inlines VIs.

Can anybody please throw some light on why and how this works so I can reset my understanding

[Yamaeda · Accepted solution]

That makes full sense to me. Consider a VI like a Case structure, and Inlining like r-clicking the case and "remove case". Whatever was inside the case/vi is now in your other vi. 

I would assume the content is 'pasted' as is, and an encapsuled property is still an encapsuled property.

Maybe I've misunderstood how things work.

/Y

[danny_t]

Hey Yamaeda,

I can visualize what you are saying and see sense in it. 

There is quite big implications I think when looking at VIM's.  If you have inside a VIM most of the heavy work done within a non inlined subVI  in your VIM and only the lightest of code within the inlined part you could get the huge benefit of the malleable VI without the explosion of the built size that could result otherwise.

Would love to hear more views on this and the original question

[Yamaeda]

---

@danny_t wrote:

If you have inside a VIM most of the heavy work done within a non inlined subVI  in your VIM and only the lightest of code within the inlined part you could get the huge benefit of the malleable VI without the explosion of the built size that could result otherwise.

---

Yes, this is an important idea/concept to keep in mind. Inlining should (generally) only be done on such small functions that the overhead of calling a function would impact performance. VIMs breaks/exploit this idea to achieve code morphing instead, which is a clever workaround of LVs limitations. 🙂

/Y

[drjdpowell]

---

@danny_t wrote:

There is quite big implications I think when looking at VIM's.  If you have inside a VIM most of the heavy work done within a non inlined subVI  in your VIM and only the lightest of code within the inlined part you could get the huge benefit of the malleable VI without the explosion of the built size that could result otherwise.

---

JSONtext is structured this way, with light API methods that are inlined (some of them VIMs) calling non-inlined VIs that themselves called small subVIs that are inlined for speed.

[danny_t]

ah, I have used JSONtext (great tool by the way many thanks) and will do again I am sure. I will take a little look at the source VI's with that in mind.

[wiebe@CARYA]

Just want to mention that inlining in for instance C++ is not different from LabVIEW.

Inlining in C++ simply means the content of the function is "copy pasted" if you will, instead of performing a function call. What is in the inlined function is not relevant*, it might as well call functions that are not inlined.

* In LV some things cannot be inlined, like property nodes and expressing nodes. I think that will improved at some time, if it hasn't already.

[wiebe@CARYA]

---

@danny_t wrote:

The workaround is to place the property node action within a subVI that is NOT inline and place that subVI in your inlined VIM. This works fine I have tried it out and it has been talked about in a number of places as something you can do.

The workaround, which is great and very useful, 

---

It's not that useful.

A .vim that adapts to a refence is still not possible. For instance, a constant and a control both have a label. But you can't make a .vim that changes the label, as you can't use PNs in .vims. Making a subVI to call the PN doesn't work, as the VI would need to adapt, so it must be a .vim, which is not possible.

So the sub VI needs to use a generic as input, and then do all the class castings to get\set the correct label property, either for constant or for control... Might as well use that subVI instead of the .vim, although the .vim has a slight benefit of type checking and avoiding a coercion dot.

So a subVI to call a property node can be a means to an end in some cases. But if the purpose of the .vim is to adapt and call a property, it's no solution.

[danny_t]

---

wiebe@CARYA wrote:

---

A .vim that adapts to a refence is still not possible. For instance, a constant and a control both have a label. But you can't make a .vim that changes the label, as you can't use PNs in .vims. Making a subVI to call the PN doesn't work, as the VI would need to adapt, so it must be a .vim, which is not possible.

---

I was not aware you could create a reference to a constant and correct me if I am wrong but you cannot change a control Label while in run-time it is a edit time only change.

However sticking to VIM's, it appears to me the reference is being adapted to correctly (in LV2018)

If I pick say Caption  "enable / disable"  control properties I can write a VIM that takes in a number of different control and indicator references (strings, clusters, numeric, array) and adapts the VIM FP control reference to the correct type. Then as you say I simply do a single cast to a Generic control type to pass into the subVI that contains the property node.

I do have a problem with passing in a Boolean type, I have not quite figured out yet.

[wiebe@CARYA]

---

@danny_t wrote:

---

wiebe@CARYA wrote:

---

A .vim that adapts to a refence is still not possible. For instance, a constant and a control both have a label. But you can't make a .vim that changes the label, as you can't use PNs in .vims. Making a subVI to call the PN doesn't work, as the VI would need to adapt, so it must be a .vim, which is not possible.

---

I was not aware you could create a reference to a constant and correct me if I am wrong but you cannot change a control Label while in run-time it is a edit time only change.

---

You can get a reference to a constant (turn on scripting). You can't change a label if the control is in run-time, never said you could. Not sure how that's relevant? If you want to make a vim that changes any label (constant, control, structure), a subVI with the property node won't solve the problem.

---

@danny_t wrote:

However sticking to VIM's, it appears to me the reference is being adapted to correctly (in LV2018)

---

Never left the .vims...

Yes, the reference adapts. But you can't use it to change for instance the label, regardless if a constant, control or structure is wired. As property nodes are not allowed...

---

@danny_t wrote:

If I pick say Caption  "enable / disable"  control properties I can write a VIM that takes in a number of different control and indicator references (strings, clusters, numeric, array) and adapts the VIM FP control reference to the correct type. Then as you say I simply do a single cast to a Generic control type to pass into the subVI that contains the property node.

---

Yes, and if you wanted to change, lets say, a label of an idle constant, control or structure, that would still work. But the vim is pretty useless, as you still need a sub VI that accepts a object, and then cast to either label, constant or structure. Might as well not make a .vim, as the .vim doesn't solve anything.

---

@danny_t wrote:

I do have a problem with passing in a Boolean type, I have not quite figured out yet.

---

Probably something to do with the Boolean type being strict. Hard to say without seeing code.