Inline sub VI test

[bsvingen]

My first scripting applications

Considering that this is my first scripting application in LV - ever, this program must be considered a proof of concept of inlining VIs, and nothing more. Most of the time was spent on figuring out this scripting (i guess i know 5-10 % of it now ), while the application itself was straight forward once i found out how to do it.

I used the alternating color vi found on this board as a starting point. I also wanted to do recursion to traverse through all the possible loops and structures, but at 2 in the morning my head just refused to cooperate with the nightmarish logics of recursion :laugh:

The way it works is to figure out the terminals of the sub vi and the closest connecting terminal on the main vi. The refs to the main vi terminals is then stored in a cluster array with the name of the sub vi terminal as the first element in the cluster. This array is then sorted. Then the whole diagram of the sub vi is copied to the main vi and all the new control terminals is stored in a cluster array with the names as the first cluster element. This array is also sorted. These two arrays now have a 1 to 1 relation for the "closest" terminal in the main vi and the copied control terminals from the sub vi, so i then wire these to together. Then i just delete the copied control terminals and the sub vi, clean up the wires, and the sub vi is inlined into the main vi.

One thing i figured out with this, was that void connector pane terminals also is considered terminals in LV, but an error is set once i try to read the wires. This means that the sub vi made for inlining cannot have any void connector pane terminals (unless the error is cleared).

The vi and a small test is included. I guess it works only for LV7.1.x

:beer:

Edit: It also works for LV8 with a small modification. Make a folder out of the llb and browse for the full vi path for the main.vi in the path window. (The strange "NI system sub vi" that i do not know what does, but seems to be needed, needs the full path in LV8, not just the name)

Download File:post-4885-1150247564.llb

[bsvingen]

I have had this in the back of my head for a day or two now, and i see that alot of testing for different posibilities have to be done for such a thing to work in all cases.

* Default unused terminals must be exchanged with constants.

* Unused exit terminals must be deleted at expansion point.

* (void) terminals must be handled correctly

* The application has to stop on errors like:

* internal terminals (cannot be allowed for inlined vis)

* graphs, charts etc cannot be allowed

* any reference to the inline sub vi cannot be allowed (although i'm not sure how this should/can be checked in a consistent manner)

* The inline sub vi cannot rely on special vi options, like default error handling, first call etc

On the other hand, i'm not sure at all if all this checking is neccesary. I believe the persons who would use inlining in the first place, would also be very consience about these constraints. ?? I know i will

Then the code needs to be recoded properly, and travirsible through all structures and also all sub vis. I think i will use the loop method for recursion that i saw an example of here somewhere, instead of the call by ref method. The loop method is probably much more efficient and certainly much easier to understand But i'm not quite sure how this willl work through layers of sub vis, since there are some basic things about scripting i do not understand (do the vi's have to be opened in a special way? etc).