strict typed clusters with configuration constant

[larsen]

I use a strict typedef cluster (call it StorageTypeDef) to define the structure of the data written to a binary file.

The nice thing here is that if I want to change the format of the data, I just modify the cluster typedef StorageTypeDef, and all referencing vi's gets updated. Unfortunate one of the elements is a string. This has a varying length and thus the size of the cluster changes.

I deal with this by limiting the string size to a maximum. This maximum value is a constant which I would like to be coded into the cluster type def.

So at all times, my cluster typedef contains ALL the information necessary to encode and decode the cluster from binary image. In this way I have concentrated my information at one location, and management is simpler.

Problem is however to make this constant number a value in the cluster typedef.

Its simple to add a variable, call it MAX_STRING_LENGTH in the StorageTypeDef cluster and give it a default value.

Problem with this soultion is that if I change the typedef's MAX_STRING_LENGTH default value at a later stage, this information does NOT get propagated to the VI's instantiating the cluster.

Neither does it work to apply Right click->Data operations->Reiniz to default value at the callers.

Inserting a new instance of the contol StorageTypeDef works, in the sense that it grabs the latest (correct)default value from the tyoedef, but it requires rewirering in all user-vi's.

Replace of the control does unfortunately not propagate default values from the typedef.

Any ideas how to pack this constant information into a strict typedef cluster?

/henning

[Grampa_of_Oliva_n_Eden]

I do not believe the type defs were ever intended to provide defalu data thay way.

I belive the the VI Analyzer even has an error that warns you about a default value in a typedef'd cluster constant.

I use a unique sub-VI to do this work.

The sub-VI simply has the typedef'd constatn with "bundle by name" nodes used to set the defaults I want. The Sub-VI returns the typed after the proper defaults have been inserted.

This technique gives you the ability to have more than one "default" value for your clusters.

I hope this made sense.

Ben

[jpdrolet]

I use a strict typedef cluster (call it StorageTypeDef) to define the structure of the data written to a binary file.

The nice thing here is that if I want to change the format of the data, I just modify the cluster typedef StorageTypeDef, and all referencing vi's gets updated. Unfortunate one of the elements is a string. This has a varying length and thus the size of the cluster changes.

I deal with this by limiting the string size to a maximum. This maximum value is a constant which I would like to be coded into the cluster type def.

So at all times, my cluster typedef contains ALL the information necessary to encode and decode the cluster from binary image. In this way I have concentrated my information at one location, and management is simpler.

Problem is however to make this constant number a value in the cluster typedef.

Its simple to add a variable, call it MAX_STRING_LENGTH in the StorageTypeDef cluster and give it a default value.

Problem with this soultion is that if I change the typedef's MAX_STRING_LENGTH default value at a later stage, this information does NOT get propagated to the VI's instantiating the cluster.

Neither does it work to apply Right click->Data operations->Reiniz to default value at the callers.

Inserting a new instance of the contol StorageTypeDef works, in the sense that it grabs the latest (correct)default value from the tyoedef, but it requires rewirering in all user-vi's.

Replace of the control does unfortunately not propagate default values from the typedef.

Any ideas how to pack this constant information into a strict typedef cluster?

/henning

Instances of a typedef are not perfect clones of the typedef. The instance can have a different label, description and default values. Default values is a data related, not type related and in the majority of cases, it is a very good thing (if not mandatory) that default values are not updated with the typedef.

If I recall correctly, there is a trick you can use to force the default values to propagate: change the numeric to a string, apply changes, change back the string to a numeric, change the default value, apply changes. Then the default values are propagated with the type change. I'm not 100% sure it works but have no time to test it now.