Your solution is way more complicated than it needs to be (like we said, your original request can be accomplished simply with a 1D array of clusters).
Personally, though, I don't really like the array of clusters for something like this, mainly because you read and write to the same control and that creates race conditions, so just to demonstrate, here's a very simple example showing the other method (LV 2009). It's not exactly how I would do something like this in real code, but the basic functionality is the same. It actually took more than 10 minutes, because I was distracted, but not much more. Note that in this example I just created "enough" subpanels (64 in this case), but it's also possible to do an arbitrary number using methods similar to your fake array.
Cober, can we have an earlier version (2011 for me, may be earlier for the others) please.
These are the files back saved to 2009, but like I said, I think this solution is too complicated. I think the example I posted shows that the other solution is fairly simple. The only thing it's really missing is a terminal that you can read a value from.
I'm very new to LabVIEW so please feel free to tell me this has already been answered or that I'm going about this totally incorrectly, but is there a way to create the subpanels programatically? I looked through your code and it clarifies a LOT of these LabVIEW pecularities on dealing with objects and setting properties that were really bogging me down, so thank you very much for that, but I was just curious if the number of subpanels is set in stone or were created dynamically. From what I can tell it looks like they're already there but I just wanted to make sure.
The posted VIs do not show you how to dynamically load VIs but you can use a basic plugin architecture where what items can be displayed in the subpanel can be loaded from disk at runtime. There are several examples that show how to dynamically load VIs.
Thanks - I actually know which VI I want to load, I just don't know how many I want to load before hand. My ultimate goal is to read this information from the "instrument" if you will, and create that many controlers for the instrument. I'm wondering if I need to preallocate this before hand or if I can get away with just adding instruments on the fly.
If you are displaying a single instance at one time you do not need to preallocate anything. You can use an array internally to keep track of any specifics and simply display the one the user selected. If you want to display more than one, you will need to preallocate th enumber of instances you do want to display at the same time. This number can be less than your total. You can implement the UI such that the user looks like they are scrolling through a list but in reality you are simply showing n number of instances. You would dynmaically load/unload the instances as they scroll. Moving instances forward/backward in the fixed number of instances you allocated.
I did actually refer to this in the reply with the code. Short version - you can't programmatically create controls (including subpanels) in LV (well, you can actually under certain conditions, and this type of use case is actually most suitable for it, but it's not worth it because of its limitations, and I'm pretty sure it wouldn't work in a VI that's already running).
What I did was simply duplicate enough subpanels. That's easy because you can select and ctrl+drag to copy, so you get a geometic progression on the number of SPs. That's why you saw that they're there. You can also write the code Mark suggested to use a few SPs and cycle the VIs through them, but it's harder and probably not worth it.
There's also some more discussion on this code here - http://forums.ni.com/t5/LabVIEW/Independent-cursors-on-array-of-cluster-of-graphs-or-work-around/m-p...
You can also write the code Mark suggested to use a few SPs and cycle the VIs through them, but it's harder and probably not worth it.
That depends, how long will this application live for and how widely will it be used? The stuff I develop has a very long life and needs to be maintained for years. I woudl much rathe rdesign in the flexibility for growth than decide I will never need more than X subpanels today only to find out tomorrow I need to add more.