Get Specific References for all Controls

[Chris_Cilino]

Gentlemen,

Given the nature of this discussion I want to run one of my ideas \ prototypes in front of you. In the next few weeks I'm hoping to publish my "pet project" that I'm calling "LabVIEW Containers". I think it could be used to help solve the problem mentioned in this thread. The idea behind the container is to merge the strengths of an array with the strengths of a cluster so that you get the following

Dynamic Size

Dynamic Access

Named Members

Hierarchy (think cluster in a cluster)

Mixed Data types.

If that sounds even a little bit interesting, I've recorded two 4 minute videos that demo the ideas and the API. I'm moving towards releasing the "1.0" version... hopefully in the next few days.

http://www.screencast.com/t/i4DVZswx

http://www.screencast.com/t/NIhFKg0oZstq

Once the "full on version" is ready for release, I'll have a whole host of pages to describe it. But for the time being this would be like a "pre release".

Side note, I've developed a "Control Container". I'd be happy to post what I have so far if you think it would be useful. Please feel free to give me any feedback as well. Thanks!

Chris Cilino

National Instruments

[RavensFan]

Very cool.  I think there is a lot of promise for a system such as this.  It will take a shift in mentality for how to use this system to its fullest potential. I think those LV programmers who have had a situation where they felt they needed the flexibility a concept such as this provides will be the first to figure out how to make it work for them.

Question:  What is the underlying LV code look like?  It seems to be a class wire, so can I assume you created a system of classes and objects to build what you have done so far?

Comment:  If you can ultimately create an example application to distribute with it.  The videos show a good start of an example.  But ideally the example will demonstrate how to work with the new concept, but with enough story behind it that it really shows that anyway you could have programmed it with existing LabVIEW architectures just would be impossible.

[martian101]

That definitely seems really useful. I've run into a number of problems that this container type seems to resolve. I'd definitely be interested in looking a bit more into the capabilities it offers, particularly with regards to VI server references/control references.

[Chris_Cilino]

Hey Ya'll

Thanks for the interest! I've pushed the early release live at th Container Landing Page. I tried posting the API on here, but it was too big. So I've accelerated my release (still some rough corners to polish up) but I really wanted to get your feedback ASAP. 

I've compiled the Container for 2013 and unfortunately some of the dependencies make it impossible for me to down compile.

RavensFan: to your first question " What is the underlying LV code look like? "

The "Container" that's getting passed around in the API is actually a DVR to a class that contains 3 objects of the same class called "Container Intermediate Representation". The three objects are for

1. Key \ Value pairs,

2. REFERENCES to other containers,

3. and private Key \ Value Pairs".

The underlying philosophy is that a parent has a table of references to each of its children, and each child has reference to its parent thus estabilishing a two way link (a child can only have one parent, so this is basically a tree implementation.)

The Container Intermediate Representation (CIR) class was created to abstract away how the key \ value pairs are managed. I've implemented a version of the CIR based on the variant's ability to contain attributes with values by name. But I could see someone wanting to use an XML string, or a data base on the back end to manage the containers.

As for your comment:  "If you can ultimately create an example application to distribute with it." I couldn't agree more with you. I've got a few ideas in mind that I've been working on. One is the idea of a "brat vi" that allows you to print \ save \ load attributes about any front panel in LabVIEW. Things like a button's color \ position \ size \ enabled state \ any vi server property. I wanted to make a framework that would allow a user of a ui a generic way to select what UI elements AND what about each UI element they want to preserve to disk. To that end I'm using Containers to develop a class called "persistable". It's a good ways off but still a thought in my mind. I have a few other ideas as well, but for the sake of bervity, I agree with you that I need to demonstrate a novel way of using the containers that is also compelling. 

One note: there is a known issue in the JSON serialization of the containers that I hope to have fixed in the near future. Basically that feature is broken at the moment as the result of a scoping bug in the lineator. 

There's lot's left to do on the containers:

1. VI documentation

2. Icon cleanup

3. Documenting all of the stuff that gets installed with the Containers VIP such as

my  test suite at ..\vi.lib\_ApplicationTools\Containers\Container\Tests),

various Demos in ..\vi.lib\_ApplicationTools\Containers

container wire probes at ..\vi.lib\_ApplicationTools\Containers\Container\SubVIs\Custom Probes

etc

I'll have an official launch page in the next few weeks. 

In any event, I really do appreciate ya'lls time in lookin at what I've create and I really appreciate the feedback.

Chris Cilino

National Instruments