Should I make cluster into a Typedef

[murchak]

Various parts of my main VI and a number of subVIs use a bunch of common controls: these controls include:

1. Single file path

2. Array of file paths

3. Array of color values

4. Single color value - BG color

5. Point style value (use for curves)

6. Max and min numeric values used for plots

and so on.

What is the best way to avoid having wires all over my BD? I thought about creating a big cluster of these values and have only one wire traversing my code. So for every instance that I need to use some of these controls, I would use the Unbundle by Name function and only select elements that are needed for that instance. Is this an acceptable way? Would this slow down my VI in anyway since the cluster wire would have to carry all the controls to wherever I use it even if all I needed for that instance would be the BG color? Would it make sense to make this cluster into a Typedef? 

[Dave_Brandt]

Yes!!!! - If you make it a type def it will update all constants created when you update and the wire will contain any thing new that is added to the cluster. It only takes a small amout of time to create a type def and will update every place used in your code.

[crossrulz]

Bundling that into a cluster does not hurt much at all as far as performance.  And I type def ALL of my clusters and my enums.  You don't want to have to update every single file just to add one item.

[murchak]

Everytime the user runs the code, the file paths are new (items 1 and 2 in my original post), but the other controls that I listed remain the same. Does it make sense to include

the file paths in the cluster? I also like to avoid having file path wires all over my BD, if possible and sensible.

[Dennis_Knutson]

Your code would be modifying the values of the controls in the cluster so I don't understand your question.

If your different states require a file path, then include that in the cluster. If the different states would require a file reference, then include that in the cluster.

[Hooovahh]

Very few times do I have a cluster or enum that isn't a type def.  I only do it on data that I am 100% sure will never change...and about 50% of the time it changes anyway and I regret not making it a type def.  In conclusion, make a type def.

[murchak]

I thought my question was clear, but perhaps not. Let me paraphrase. (Main code takes an array of data files (via File Dialog vi) from the user and creates formatted tables and many XY plots)

The array of colors (used for curves in my different XYGraphs), background color, point style, grid color, X-axis and Y-axis min and max values, and line width are all constant and almost never

change unless I change the background color or something  for aesthetic reasons. It makes sense to put these controls in a cluster and make the cluster a typedef.

Now, everytime the code is run, the user is asked (by the File Dialog vi) to select the data files generated by different test samples. The array of files coming out of the File Dialog vi is fed into various parts of my main VI as well as into some of the subVIs. Therefore, I have file path wires all over my BD and wanted to know if there is a way to clean that. I thought about bundling the file paths so at most I would have one main wire running through my VI and use the unbundle funtion to only select a subset of file paths whenever needed. I guess this should be separate from the cluster of constant controls that I mentioned above.

[Dennis_Knutson]

I do understand your question. I don't think you understand clusters, whether typedefed or not.

[murchak]

Hi Dennis,

Not to quibble over this, but above you clearly stated that you didn't understand my question, and NOT that I didn't understand clusters. 

But now that you think I don't understand clusters in the context of how I am using a cluster, please feel free to provide some help. I would appreciate it.

Is putting all the constant controls in one cluster an incorrect use of a cluster? Given my limited ability with LabVIEW, I cannot write 

professional looking code with professional efficiency, so assuming that I have these controls and I must use them in different parts

of my main VI and parts of my subVIs, what is the best way to cleanup the wiring of my BD? Suppose I use background color grey in

twenty different places in my code. Should I create one background color and run twenty wires from the same color control? Or should

I create twenty copies of the background color control? What about creating twenty local variables from the background color grey? Now, what if my code

also uses an array of colors to color different curves with different point styles? This would multiply the number of wires in my BD. How should I approach this

problem. Any suggestions? 

Thanks in advance for the help.

[Dennis_Knutson]

Sorry, I understood your need for a cluster but not the question about values in the cluster. I would populate the values from reading an ini file or you populate it from an action in the code (i.e. your dialog or results from somewhere).

I would hope you are using some sort of structure like a state machine so the cluster would be passed to each state with a shift register and each state would have an unbundle by name where you want to read an element and a bundle by name when you want to change the value of an element.