Why Type Coercion when using VALUE property?

[CoastalMaineBird]

I have an editor, displaying a config file. LabVIEW 6.1.
The screen shows an array of clusters, only one of which is showing at a time.
The cluster contains numerous elements, one of which is an enum labelled HARDWARE TYPE, which is an instance of a TypeDef (in a CTL file).
The cluster itself is a TypeDef called CHANNEL CONFIG, although I don't think that matters.

On the diagram, I need the value of the currently showing HARDWARE TYPE to decide to enable / disable other controls in the cluster.

Rather than indexing the array, and unbundling the element, I am using a property node for the control, and using the VALUE property to decide what to enable and disable. I am passing this value to a pair of subVIs (be
cause this is done in more than one place).

The subVIs have controls which are instances of this same HARDWARE TYPE TypeDef.

The whole thing works just perfectly.

My question is: Why do I have a type-coercion dot where the wire goes into the subVI(s) ??? Given that both ends of the wire are instances of the same TypeDef, what coercion is needed?

It does not matter if the TypeDef is strict or not. I have verified that all these things derive from the same root TypeDef.

I can copy the front panel control onto a new VI, put the subVI on a new diagram, and connect them without coercion. Why does the VALUE PROPERTY require a coercion?

[Ben]

Hi CoastalMaineBird,

Please post a demo of this.

Lacking the demo, let me post a guess.

Are you using a typedef'd array of typedef'd clusters?

The typedef'd array will give you coercion dot if you any method of building the array OTHER THAN replace array element.

Even build the array on the edge of a FOR loop will give you the coercion dot.

That is all that I can think of with the info you provided.

trying to help,

Ben

[CoastalMaineBird]

Attached is the demo. The main VI shows the real cluster I'm using, minus a few other TypeDef'ed clusters that aren't relevant.

The HARDWARE TYPE TypeDef is included as well as another TypeDef that shows the same symptoms.

I'm not building the array here, I'm just extracting a property value.

[JeanPierre]

CoastalMaineBird,

For some reasons, the data type of value nodes is not exactly the same as their associated control. Typedef information and data names (items names of a cluster) is stripped from the type. That is why the coercion dot is shown: the data type is indeed the same but it is not linked to the typedef of the control.

[Ben]

I am not going to be able to answer this Q!

Doing a ctrl-H with the wire tool shows that the value property is (as Jean_Pierre mentioned) is not of the data type in the typed-def.

I was able to type-cast it and got rid of the coercion dot.

How did you create these property nodes?

It almost looks like they were created from a non-typedef'd cluster that was latter edited and replaced with the typedef.

I was not able to create a new property node.

How did you create these nodes?

Ben

[CoastalMaineBird]

I was not able to create a new property node.

How did you create these nodes?

In the demo I sent you, I had the TypeDef set to STRICT, and you can't create a property node from that. If you set the TypeDef back to non-strict, and save it, you can create a property node from an instance.

BUT THAT IS EXACTLY THE POINT. A Property Node's VALUE is not the same type as it's terminal???

I just did some more fiddling and found that the array is irrelevant, the cluster is irrelevant. If you place an instance of the control on the panel and wire the terminal to the subVI, there is NO coercion. But if you wire the VALUE property to the subVI, there is.

I have attached a smaller demo that proves that the VA
LUE from the PROPERTY node, is not the same type as the value from the TERMINAL. It's not related to the cluster, or the array at all.

I'm just curious as to why.

[JeanPierre]

Indeed "the VALUE from the PROPERTY node, is not the same type as the value from the TERMINAL".

This impacts your code in two ways I can see at once:
- coercion dot for typedefs. This is a minor issue.
- you can't unbundle by name a cluster from a value property. This is more annoying.

As to "why" I can just guess. A property node uses an implicit typed control reference to the control. The way typed control references are currently implemented in LabVIEW, the type only include the datatype stripped from typedef links and datanames. As long as the data structure is the same, this allows the typed control reference be assigned to controls linked to different typedef or to clusters having different element name
s. This allows more freedom to what type of controls the control reference can refer.

To keep typedef and datanames, one would need a new type of control reference that would be strictly typed to only one kind of control, and restricted to refer only controls having the same typedef and datanames. Only then the coercion dots would disappear and unbundle by name could be used with property values nodes.

[CoastalMaineBird]

Apparently it's just a LabVIEW bug ^H ^H ^H ahem, undocumented feature.

I just loaded the 2nd demo into LabVIEW 7 and there is no coercion dot.

[Ben]

From what I understand of LV 6.1, I am suprised you get away with the disconnect from/re-connect to the typedef without complications.

It was not that long ago that the typedefs did not come along with the wires. It ma have been 6.1 that started this.

With what you report about LV7 it sounds like this propagation of typedef info was enhanced in LV7.

I would vote that you did indeed discover an "undocumented feature".

Ben

[CoastalMaineBird]

you can't unbundle by name a cluster from a value property.

I hadn't thought of that but you're right - you cannot. The UNBUNDLE BY NAME function has no names in it, when wired to a VALUE property of a cluster. When wired to the terminal, of course, it has the names.

In LabVIEW 7, it works as you'd expect - the UNBUNDLE function has names, either way.