allow user created growable functions

[falkpl]

Many built-in functions have the growable ability. Essentially a function that accepts an array of data in scalar form, this saves the step of building an array prior to wiring a terminal.  I would like to select any  1-D array on a connector pane and mark as growable.  Then when the vi is used as a subvi, the icon would have the growable ability.  This could have been used as for example for making a growable error handler or implementing new compound math functions.  I know this is probably hard to do and might be possible with xnodes but I dont have time to learn this.  It is useful for making reuasble toolkits which look more like the native G functions

[tst]

>I know this...might be possible with xnodes but I dont have time to learn this

It is. Perhaps the request should be to make XNodes public and easier to use.

[AristosQueue (NI)]

The suggestion is good, but the implementation has a lot of details that would need to be worked out, especially to hit that "easy to use" target.

We would need to be able to handle several different use cases for growable nodes. I can think of four:

A. A growable node such as Compound Arithmetic needs all of its inputs to calculate a single output.

B. A growable node similar to Index Array but without the default value for index terminals behavior can represent multiple calls to the same routine -- each input produces a separate output. You could imagine a subVI with one array input and one index input, and that subVI gets called N times, where N is how many times the node gets grown.

C. A growable node such as Index Array is very much like B, where every input produces a separate output, but there is special behavior on Index Array such that if a terminal is not wired, it gets the value of the previous index plus one, so there is some interdependence.

D. A growable node such as Scan From String uses a sort of chain behavior, where each input represents a call to the subroutine, but each call uses the part of the string not used up by the previous call.

Based on those cases, I'd like to hear customer suggestions for the following items:

1. Is vertical growing only acceptable or would you want horizontal growing for terminals on top?

2. What sort of UI manipulation would be needed to indicate that a VI is growable and which terminals should replicate each time the node grows?

3. What does the block diagram look like for growable terminals? Does each growable terminal become an array of values (or, if the terminal is an array type, an array of cluster of array)? Is it still a single input, and we just run the block diagram N times?

4. What happens to the front panel? If you're debugging, how would you want LV to display all the grown cases? (This may have different answers depending upon the answers to #3.)

5. Are the answers to 2, 3, or 4 different depending upon which use case (A, B, C, or D or some other that you come up with) you're implementing?

[falkpl]

Yes I figured there would be lots of interesting problems associated with such an implimentation that exposes these advanced features of a VI.  I was looking as it in the most simple form initially, vertical grow of a single input terminal linked to a predefined 1d array type. only one terminal (Lower left of the connector pane) allows for the inpun of 0+ scallars instead of a bundle and array input into the vi.  This was just a first attempt at a suggestion exposing an ability of a vi.  (Really the adapt to source in the ability I really want- so we can make generic functions but I need much thought before formulating a idea on that topic).

Thanks for the great insite on some of the issuews with an easy button for vi abilities.