Should I make cluster into a Typedef

[murchak]

Okay. So suppose I write a piece of code in the "beginning" part of my main VI, whose main function is to initialize an INI file.

In the .ini file, this piece of code puts the following: all file paths and constanst that my code will use at some point. 

Then, in the main part of my VI, do I drop a file path control and open up the .ini file and read whatever I need to read? Is that how

an .ini file works?

[Dennis_Knutson]

No, not at all. The point is to READ at the beginning.

[murchak]

Dennis,

No I clearly do not prefer to change the whole VI if colors need to be changed. So let me put it this way. The code is used by the user who just needs to select the initial files.

They have no control over how the plots are presented. I take care of that. But for the sake of generality and good coding practice, I agree with you that I should find a way

to make minimal changes if I need to change the looks of my plots. So going back to a few posts ago, if I created these constants and put them in a cluster and use the unbundle

by name function to extract a particular element from the cluster, then someday in the future if I were to change the background color, don't I just have to change that element inside

my cluster (make the new values default) and save my VI and isn't that all I need to do? Why would I need to change anything else in my code? 

[murchak]

Thanks Dennis. This is where a simple and concrete example would be of great value.

[Dennis_Knutson]

We have gotten off the topic of creating a type def but the difference is a flexible design versus one that isn't.

[billko]

---

@Dave_Brandt wrote:

A Global would require a code change, Why not Just use a file for constants? If the file is in xml or a csv format the constant value could be changed with notepad or any simple text editor. I think you should use clusters but the data in the cluster should relate to each To be logically grouped. Do not have one big cluster so there is only wire in your block diagram.. This could slow your program because labview would not be able to parallel process data but would follow the wire path through your code through each sub vi.

---

I'm not sure what you are saying here.  You still have to read the values and put them somewhere.

Oh now I think I get it.  The point wasn't really to use a file for constants like you led me to believe; actually what you are saying is to read all your values into separate clusters instead of one humungous global (regardless of where they are being read from - which is usually a file, of course).

Still not quite sure what you mean by the first sentence, though.

[Dirtboy]

If you make your cluster a "strict typedef" then whenever you edit and save the original typedef, the change automatically propogates to every place where that typedef is used.

So, if you made a control/cluster, named "RedBackGroundPlot.ctl" and another named "BlueBackGroundPlot.ctl" etc. then you could create an arsenal of these various color schemes and use them at the appropriate locations. Unbundle by name would let you access any specific field.

If you had a subset of the fields in the cluster that were truly constant then you could make a typedef for those values, and then include that typedef in your arsenal of variable typedefs.

For example. Suppose you define a rectangle with "height" defined to 100 and "width" defined as 200. Now you save that as a typedef, named "RectangleDefinition.ctl"

Now you define "RedColorScheme" and it contains your value to define the color, (RGB value, string, whatever you are using) plus the "rectangle" thing.  You're on your way to object oriented programming!

[Dave_Brandt]

The apparence of your front panal can be changed by opening a configuration file that initializes (change) values for your austetic apperance. To change how the code works requires a programing change on the block diagram.

[mikeporter]

The thing to remember is that the point of a cluster is not to simply allow you to pass more data through a single wire. When you create a cluster you are defining a custom data type. This fact has two implications:

First, a cluster should almost always be typedef'd.

Second, a cluster should encapsulate all the data needed to describe something.

For example, a cluster might describe the UUT (unit under test). It might describe the state of your application, or it might describe the results of a test.

You need to give some careful thought to the data structures you use because you get them wrong and it can make your project exponentially more difficult. But get them right and sometimes the correct solution just sort of falls out on the floor.

Mike...

[Bob_Schor]

One other (maybe trivial) advantage of defining a TypeDef for a clster comes when you need to create a Cluster Constant on your block diagram.  If you create a nice icon for your cluster, then if you double-click the cluster constant on your Block Diagram, it will be replace with the icon you created for the TypeDef.  Can make your Block Diagram more self-explanatory (as you'll know the icon for the cluster you are building).  Now if this icon behaviror also worked for other types in addition to clusters ...

BS