Complex data structure.

[Jackson_Peacock]

Hi,
This is a design issue that I have run into many times and I was wondering how you all solve it. When using complex data structures (such as array of clusters, or clusters containg arrays and/or other clusters), I have found that there are many situations where you need to wire either an "empty" stucture or the type of the structure as an input. For example, when building up the data structure, I often use shift registers, and need an empty data structure to initialize the shift register. Also when bundling a cluster by name you need the type of the cluster. My question is - what do you use in these situations? Of course, I always typedef my complex structures, and I know that there is a default value for them, because other language featu
res depend on there being a default. Is there anyway to get the default value for a typedef? Not seeing one, I have taken to creating a Global or Dummy VI for each typedef that returns a default data structure, which is what I use in all these situations. What other approaches have you seen?

[Greg_McKaskle2]

> of the cluster. My question is - what do you use in these situations?
> Of course, I always typedef my complex structures, and I know that
> there is a default value for them, because other language features
> depend on there being a default. Is there anyway to get the default
> value for a typedef? Not seeing one, I have taken to creating a Global
> or Dummy VI for each typedef that returns a default data structure,
> which is what I use in all these situations. What other approaches
> have you seen?

You can right click on a wire or terminal and create a constant for the
type already there. This will sometimes fool you if you are wanting the
input to a shift register since the types flow downstream and you want
upstream. Just click somewhere whe
re the type is known, create the
const and move it where you want it.

The BIG downside to this is that typedef constants tend to be BIG. My
favorite solution is to make a subVI that returns the default for the
typedef. Put it in user.lib and it is readily accessible. You can
think of it as a constructor for your datatype, if you want. In fact
you can make several of these or parameterize it to return different
flavors. Being the size of all other icons, it fits nicely into the
diagram and adapts to typedef changes.

Greg McKaskle

[Ben]

I like the typedef constant wraped in a sub-VI.

Alot less space on the diagram, and no issues when the typedef is modified and the updated constant on the diagram ending up larger than the structure it is in.

Another plus is that it can be used to establish default values. Any filed of the typedef that should have a specific default value can be implemented by doing a bundle by name inside the sub-VI.

I have seen code fail because a constant on a diagram lost its default values when the type def was updated. This makes sense to me becuase if a new field is added to the structure we do not know what its defaults should be.

So you get
1) Smaller diagram foot print
2) Ability to define global default values

by wraping the default in a sub-VI.


Ben