Ok, I think I see. You have this display that mirrors the memory map for some device that you are testing/programming. When run, the operator manipulates the various various controls associated with each memory location in the target device, and then has the option of saving those changes. I assume that the other tabs have the same basic task, but differ in the specifics of the memory map that is displayed.
To start, consider that the possible combination of controls is actually rather limited, if you think about it: You can have up to 8 bit buttons and 4 popup controls (since you are using popups for values that are encoded in two or more bits) - or some combination of buttons and popups. So all the variability you really need for each memory location is the ability to make 8 bit controls appear or disappear, and the ability to change the visibility, position, width and strings of 4 popups. In addition for all 12 objects you need to be able to set their captions. The idea is that for a given memory map the code would control those 12 elements to make each row different, when it is actually the same cluster datatype that you are making
appear different by manipulating the property node associate with each of the 12 items in the cluster. This cluster should be a typedef.
Given that there are 10 memory locations on the page, you will need 10 of these clusters. So to simplify the processing you want to place those 10 independent clusters into a single cluster. The result is that the top-level data structure for the display will be a single cluster containing 10 copies of the typedef'd cluster.
Now to allow your code to manipulate this display, you first need two arrays: One contains the description of how each typedef'd cluster should
appear, defined in terms of the things listed above. The second array holds the data that each typedef'd cluster
contains. These are maintained separately because the cluster definitions are only changed when the target memory locations being edited are changed, where as the data changes as the user manipulates the various controls to change the contents of each memory location.
In terms of code (and I am assuming an event-driven interface here) you will need, to begin with, an event for initializing the display. This event includes a subVI for reading the cluster descriptions from wherever you decide to store them; a subVI for initializing the appearance of the display; a subVI for reading the data to be display (presumably from the target device); and a function to fire the
display update user event described below.
Next, a
display update user event will contain subVIs that take in a reference to the top level cluster, the array of descriptions and the array of data and updates the display to show the data.
Finally, a third event (a value change event on the top-level cluster) contains code that using the
NewVal and
OldVal event data determines what value the user has changed, updates the data array to reflect that change and fires the
display update user event.
You might also be able to meet this requirement using X-controls, but years of beating my head against walls has taught me to not implement new features too soon. For example,ActiveX controls were introduced in LV V5 but it took a couple revs of LV to get them to the point where the kinks were worked-out enough for them to be usable in a deployed application. You don't want to structure your code based on some new capability only to find out that you are pushing it beyond what NI had tested and it contains bugs that prevent it from doing what you want to do.
In any case, the point of this post is to outline the approach I would use to address this design challenge. To demonstrate that this really does work, the example at this
link shows the interface to an application that I created using the basic technique I have described here. It implements a scrolling list that appears to have different data in each element. Extract the contents of the archive into a folder and run the VI
~Interface Test.vi.
I understand that this is probably a much larger answer than what you were looking for, but this is a complex interface that you want to create. However, if you decide to go forward with this you will learn a lot about how LV works and how to design an application. If this sounds interesting let me know and we can start stepping through the design/implementation process...
Mike...
LabVIEW user groep 
