dynamic terminals

[falkpl]

I am not sure if this is possible but it is a function which could be very noce to have, a generic control input type that will adapt to the wired input.  Polymorphic vi can get this started but you have to define a vi for each permutation of types (with clustering and arrays this becomes infinite).  I know that I can flatten any to string or convert to a varient but I want this ability without requiring the intermediate step of data type conversion.  There are numerious vi I could implement if this feature is exposed but I can not figure out a way of doing this.  since NI has many built in functions adding such a feture should be possible.  Am I lead to believe that these are not pure G functions?

Paul  

[JDave]

I believe many of the built-in functions are polymorphic.  This is the only way I know to do what you are asking for.

[falkpl]

I tried this with polymorphism but how do you handle different types of clusters and arrays.  Since these have many possibilities I can not define all permuataions.  Am I missing something?  Can I define a generic cluster or array?  If a cluster is inputted I could easily recurse over all controls[] and for an array I can easily do a for loop an each element.  And keep with this approach until I handle all controls down to a native data type.

Paul

[tst]

The primitives (the yellow icons) are not G code.

What you want can be accomplished by using XNodes or express VIs. See here for an example or search the LAVA forums for other XNodes related examples (there are some in the code repository). You should note that XNodes are not supported.

Also, I'm assuming it's not impossible that NI will include something like this in future versions of LV.

[F._Schubert]

You could use references to pass clusters and arrays (and other controls as well). Then use the property node to extract and determine the type of the elements. Have your VI called recursivly via VI-Server to get the nested structures. Sounds like good fun coding...

In fact, I used references to clusters with just one data type (string or numeric), then property node to get the elements (Controls[]) and in a for loop extract name and value. It is a good reusable VI for saving data. If I have spare time or the need to, I'll for sure going to implement such handling via data type (at least strings and numerics) to have it more flexible adapt to my data.

And I guess you won't need to cover any possible data type (think about the 20/80 rule) and just add new data types if needed (as they come by).

Felix

[falkpl]

My cunent implementation is based on the control reference, it just sucks that I have to break the data flow to get the reference of the control to pass to my subvi, then the subvi will invoke the proper vi based on the reference class name. I was looking for a more elegant solution that ni is not yet released to the community. 

[TCPlomp]

---

@falkpl wrote:
My cunent implementation is based on the control reference, it just sucks that I have to break the data flow to get the reference of the control to pass to my subvi, then the subvi will invoke the proper vi based on the reference class name. I was looking for a more elegant solution that ni is not yet released to the community. 

---

What's the difference between this and a Variant input?
A way to break down the variant is shown here.

Ton

[shoneill]

Casting to Variant makes a copy AFAIK.

Using the native "G" Datatype is more efficient.

Shane.

[F._Schubert]

Using property node: Value is generating a copy as well, but furthermore there is a thread swap (because the control value is in the UI thread).
Although I proposed & use the references, I consider the variant way to be better. The main reason is when the data copy is made. If I have a control in the GUI and my operation is slow, the value might already have changed when I read it by the reference (and race conditions are annoying to debug).


Felix

[falkpl]

Thanks for all the input, I guess using the variant is the best anything in input but I will have to do more work to handle and manipulate the code.  I did find the lava discussion of xnides very interesting and if I ever get some down time I will definitly explore that avenue.  lots of cool stuff here.  Are there any limitations to variants, I have used them but not all that often.

Paul