The LabVIEW Container

[Chris_Cilino]

Hey Ya'll

I've created something new that I'd like to get your feedback on. I'm calling it the LabVIEW Container. Think of it as a cross between an array and a cluster. Another way to think of it is an "in memory cluster" that you can programmatically interact with. Other languages have a "Dictionary" so I wanted to make a LabVIEW flavor.

Here's a short 5 minute video

Here's the link to the community page where I explain it in detail

I'd love to hear ya'lls thoughts \ feedback. This is still very much a work in progress....

Chris Cilino

National Instruments

National Instruments

[ToeCutter]

Hi Chris,

I only read your intro, not played with it, but it looks very useful and well packaged.

Could come in useful in future, thanks!

[warEagle12]

Hi Chris,

I think this is a really cool idea! It seems like it would be quite useful in certain cases, especially if someone wants the functionality similar to dictionaries in other languages as you said. I watched your video and downloaded the package and played with it a bit. I expanded the example that you showed in your video to include attributes of different types-a numeric array, string array and boolean array. I love the idea! Right now I'm having trouble getting the attributes if I try to get them by type (it says that data type of the variant is not compatible with the data type wired to the type input), but I am going to continue to play with it. I have attached the simple code that I am working with if anyone wants to take a look. I'll continue to tinker with it, but sounds like a great idea so far! 

Steph

[Chris_Cilino]

Hey Stephanie

Thanks for checking out the idea!!! You've put your finger on a sore spot that I forgot to include: 1D arrays of the types. As of 1.0.1.34 you'll need to do something like the following if you want to access an array.

I intend on expanding the list of supported data types so to include 1D arrays of those types. But in the mean time, the accessing the attribute as a varraint and then casting it to the type of interest should get ya squared away.

Thanks again!

Chris Cilino

National Instruments

[warEagle12]

Hey Chris,

Thanks for the work around, that's great! Makes a lot of sense. I'll continue to tinker with your toolkit. Great work!

-Steph

[JKSH]

Hi Chris,

Great stuff! I'm looking forward to seeing your work integrated into LabVIEW proper.

I was wondering, is it necessary to have 2 separate VIs for getting/setting Containers vs. Attributes? Could the API be simplified by using the same VI for both? For example, in the diagram below, "My Top Container" has 4 children:

1. A child with the key "My Sub Container" and a value of the "Container" type
2. A child with the key "My Numeric Array" and a value of the "I32 Array" type
3. A child with the key "My String Array" and a value of the "String Array" type
4. A child with the key "My Boolean Array" and a value of the "Boolean Array" type

Some comments about the names:

• "Container" is very generic. Arrays, queues, maps, stacks, etc. are all commonly described as containers. How about a more descriptive name? Some suggestions:
• Map/Dictionary/Associative Array
• Data Node
• "Attribute" sounds like a characteristic or property of the container, but we're actually describing the contents of the container. Some suggestions:
• Element (Most consistent with other LabVIEW containers -- think of "Array Element", "Cluster Element")
• Item
• Child

[Chris_Cilino]

Hey JKSH

I 

think there are two reasons I wanted to have separate API calls for the addition of a container vs an attribute.

1. Naming for a container vs an attribute occur at two different places. The container's name is specified at instantiation and the container can have construction info. The two sub classes, control and vi, take in additional parameters for example. The attributes are named at the same time their values are specified. It just seemed like the "creation operations" of an attribute vs a container were sufficiently that to combine them into a single API function could cause some confusion.

2. A container can stand on its own whereas an attribute can only exist in a container.

I really like your naming schemes better than what I've come up with. I'm leaning towards data node personally. I should start a poll. My goal in using container was because I wanted to use a term everyone was already familiar with or was a term someone might intuitively search for when looking to create a data node like thing. But in all honesty, I think you're right.

Thanks for following up. I've just transitioned into the Marketing group at NI, so I'll have less development time to invest in the idea. I may post the source so that people can start iterating on it, similar to what Sam has done on LabVIEWHacker.com. But this is a topic that's near and dear to my heart so it is NOT dying.