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.
I'd love to hear ya'lls thoughts \ feedback. This is still very much a work in progress....
I only read your intro, not played with it, but it looks very useful and well packaged.
Could come in useful in future, thanks!
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!
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 188.8.131.52 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 for the work around, that's great! Makes a lot of sense. I'll continue to tinker with your toolkit. Great work!
Great stuff! I'm looking forward to seeing your work integrated into LabVIEW proper.
Some comments about the names:
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.