Customizing X-number of Controls at Runtime

[CodeSDz]

I am new to LabView but have a strong programming background.  Basically, I'm looking for some guidance on the standard (or "right") way of building my application.

Application goals:
-- Monitor several freezers to ensure temperature remained in a specified range.
-- Customize data for each sensor (Name, Thresholds, number of sensors, etc)
-- Save temperature information for later retrieval.

FYI: I use the TInScan VI which outputs an array of up to 16 temperatures.

Front Panel:
I made a strict typedef control with the indicators in a cluster (sensor_clu), then arranged the 16 controls in main_cluster.  My programming instinct said use an array as I have 16 objects of the same type.  However, I wanted a grid layout (4x4 numbering left to right, then down), and the ability to hide unused sensors.

Block Diagram:
My block diagram strengthened my feelings that I shouldn't be using a cluster as a "pretty" array.  I don't like that the program blindly converts a generic object to a specific object based on the order of controls in the cluster.  I feel that there should be a way to keep all of my controls, clusters, etc in their original type, or at least a way to convert a generic reference to a sensor_clu. 

for loop idx:main_cluster-->Controls[] prop      // for each sensor_clu
  convert reference to specific class: Cluster   //   convert ref to cluster
  for loop idx: cluster object-->Controls[] prop //   for each control
    case structure: iteration number             //     determine control
      convert reference to specific class:       //       convert ref to control
      finally set any properties of that control //       set values
                 
Please offer any advice on this topic.

FYI: I am using LabView 8.2.1


Message Edited by StevenATK on 07-29-2008 01:07 PM

[johnsold]

This is one of those areas where there may not be a standard way of doing things.

A cluster is nice if you need to handle all the various pieces as a whole. Your strict typedef sensor cluster is a good example.

Since you want to vary the number of these which show on the panel, perhaps placing sixteen copies of the sensor cluster as individual controls might be best. This allows arranging the panel for the best appearance. Then on the diagram use the build array function to create an array with the clusters in it. Your code can then use the efficiencies of array handling, autoindexing, ... You can also create an array of references to the controls and use those to set the Visible properties for the controls you want shown.

Lynn

[TCPlomp]

First advice:
Don't use a strict typedef, a normal typedef will do (a strict will also include information about the representation of the GUI elements).

I would use two arrays, one 1D-array for the actual data. One 2D array for the representation where you position the freezers at the right point.

---

Block Diagram:
My block diagram strengthened my feelings that I shouldn't be using a cluster as a "pretty" array.  I don't like that the program blindly converts a generic object to a specific object based on the order of controls in the cluster.  I feel that there should be a way to keep all of my controls, clusters, etc in their original type, or at least a way to convert a generic reference to a sensor_clu. 

---

Could you describe (or show) what happens here? I don't really follow.

Ton

(small second advice, don't typedef the array but the cluster inside the array)


Message Edited by TonP on 07-29-2008 08:33 PM

[CodeSDz]

Finally!

After playing around with my design all week, I finally found what I believe to be the best solution.

Front panel:
I decided to keep the main cluster of 16 "sensor clusters" arranged in the grid for the original reasons.  I bet there is a way to create n-controls dynamically, but 16 isn't that many to put in manually.

Block diagram:
I finally discovered how to use a variant.  I iterate over the references of each "sensor cluster" in the main cluster setting the value.  The value is controls bundled into a cluster of type "sensor cluster" converted into a variant.

[Ben]

Steven posted " I bet there is a way to create n-controls dynamically, ..."

You are correct but if the same challenge can be solved using a limited set of FP objects, then there is no reason to make your (and the developer that follows-up behind you when you retire) life harder than it has to be.

After all, we are talking about LV and not C.

Ben