large number of terminals in a sub vi

[cosborne]

I have a VI which I use to save and recall application configuration data to a file.  To cut down on the number of terminals I'm using clusters.  Output data works well enough with the "Unbundle by Name" control.  For the input data I use a cluster typedef and the "Bundle by Name" control.  This works but seems rather clumsy.

What would be preferred is some method equivalent to how a property node operates where I can dynamically expand and select the IO terminals.

I can get close to this approach when I deselect "View as Icon" in a subvi.  The problem here is that I'm limited to the number of terminals available.  Also, having the list be hierarchial (like a property node) would be great.

Is there any way to create my own "property node" type input/output control with dynamic resizing of the IO selections?

[LandBelenky]

You probably knew this already....If you nest one cluster inside another, you can address them in a heirarchical manner, as shown below.

I use cluster input/outputs for just about everything I do and find them to work very well and not be clumsy at all.

Can you post your vi? 

[cosborne]

You have the right idea on how I'm handling the clusters.

To send/receive data to/from the VI I use:

1. "Bundle by Name" control wired to VI input

2. Typedef constant (displayed as an icon to reduce size) wired to "Bundle by Name" above

3. "Unbundle by Name" control wired to VI output

What would be great is to have a "property node" type interface which would eliminate the need for the above 3 extra components.

[johnsold]

Are you aware that you can expand or contract the Bundle and Unbundle nodes to show only the elements to which you will be connecting wires?  You can also pop up on the node to select the element.  This seems very much like your request to do this with property node.

Lynn

[cosborne]

I believe my description could use some help.

This image shows the difference I'm referring to.

The first example sets/gets values using a "Bundle by Name", Cluster constant, VI, and "Unbundle by Name".

The second example is the VI with "view as icon" unchecked -- this is OK but there is no hierarchy and I'm still limited in number of terminal selections.

For the second example I would, in practice, try to match every value in the cluster with a terminal.

The third example is a property node which accomplishes the set/get with a single control.

Don't get me wrong, the first example is workable but the third method (if possible) would be better (in my opionion).

[JÞB]

Make it a Class! create read and write accessors and use a property node to access them

Edit: don't say it takes too long.  I posted created the example and EDITED the post

[jcarmody]

Replace your cluster with a class (LVOOP) and, when you make the accessor VIs, configure them to be available in a property node.

[cosborne]

The class option looks like a good idea.

After doing some quick tests I have 2 comments--

1- It looks like the class needs 2 vi's (get/set) for each variable so I'm looking at dozens of small accessor vi's.

2- It doesn't appear that I can create a hierarchy with the "property node" option.  Everything is presented in a flat structure

Is this just the nature of OOP in Labview?

Also, the difference between a class and an object are somewhat blurred.

I recently upgraded from version 7.0 so I'm still looking through all the new options and features.

On a sidenote -- I really miss the tiny 10MB runtime engine.

[JÞB]

Yes, Class and object are slighty blurred in LVOOP from a "pure" Software engineering perspective.  Of course, niether would exist alone!    The "Dozens" of small vi's are actually "Auto Generated" by a wizzard from selecting the class>Right-click>>Create>> ... and clicking a few options.  Relatively painless!!! and the reason why I was able to create the example within the editing time window (On purpose to show how QUICKLY you can program with LVOOP-- and I don't use Quick drop!....Well, I'm getting better at that too....but I didn't need to use it for the example.)

As far as "Hierarchy" a class can contain another (sub)class as a member of its private data.  A dot notation property node to peek inside is a locical extension of the current LabVIEW class implementation and if NI R&D hasn't thought of it yet--- there is the Idea Exchange.  Link to the Idea here and I'd vote for it!

[SteveChandler]

---

@cosborne wrote:

The class option looks like a good idea.

After doing some quick tests I have 2 comments--

1- It looks like the class needs 2 vi's (get/set) for each variable so I'm looking at dozens of small accessor vi's.

2- It doesn't appear that I can create a hierarchy with the "property node" option.  Everything is presented in a flat structure

Is this just the nature of OOP in Labview?

Also, the difference between a class and an object are somewhat blurred.

I recently upgraded from version 7.0 so I'm still looking through all the new options and features.

On a sidenote -- I really miss the tiny 10MB runtime engine.

---

[Edit: Looks like I had a post collision with Jeff. Based on your comments I am sure you understand most of the things below but my mindset when posting is the wider audience that may be lurking. It is really meant to encourage everyone reading (not just you) to start using LVOOP)]

You can automatically create the accessors. You add data items to the class control just like any cluster. You then right click on the class and select "create accessor". You select the data item (or multiple items) and if you want a read, a write, or both. There is a checkbox to make available via property nodes.

The difference between a class and an object is that the class is the definition of the object. You create objects from the class. Somewhere in LabVIEW there is code that defines what a numeric control is and what it does. When you place one on the front panel you have an object. That is probably not totally true but it is pretty close.

Dive in! The water is great! My advice is that you just take it easy and stay out of the deep end until you get comfortable. What I mean by this is don't worry about things like community access scope or inheritance. Just get comfortable with the mechanics at first. At the lowest level LVOOP is pretty much just a type defined cluster and a collection of VIs that have permission to bundle and unbundle to that cluster. Plus you can make your own custom wire apearance to match your favorite football teams colors.