LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
SteenSchmidt

New Inline Code Node

Status: New

In my opinion VI Properties/Execution is the wrong place to decide if a VI should be inlined or not. It should be on an individual instance basis, hence I suggest a new Inline Code Node:

 

InlineCodeNode.png or InlineCodeNode2.png or InlineCodeNode3.png or InlineCodeNode4.png

 

You should be able to either drop a subVI as usual, or you can drop that subVI into an Inline Code Node if you want it inlined. The new Inline Code Node doesn't have VI refnum inputs, as the definition must always be static (to allow for the compiler to inline the code at edit time). With an Inline Code Node you can inline existing subVIs, no matter their inline setting. It is you who programs the caller who knows if it makes sense to inline the subVI or not.

 

Since execution of inlined code differs quite alot from an ordinary subVI (and possibly even more in the future), it will make sense to highlight this difference with an Inline Code Node.

 

An Inline Code Node would also make it possible later to remove the synchronization barrier that is in place in the current inlining implementation, since when you debug with execution highlighting enabled, it should no longer be surprising if the Inline Code Node runs before any inputs are ready, nor should the asynchronous behaviour of IO surprise (since that's the defined behavior, and has to do with the Inline Code Node and not the subVI you've embedded in it). If you can step into such an Inline Code Node or not when debugging, would be up to the debugging capabilities of the version of LabVIEW you use. Maybe you can't do that now, but it might be possible in LV 2015 (just as it maybe would be possible to step into a Call by Reference Node at that time?).

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion