Can strictly type refnum control do type coercion?

[steady]

Hi all,

Can strictly type refnum control do type coercion? NI says yes:

A control refnum terminal that is strictly typed can only accept control references that are strictly typed to a compatible type. For example, if a subVI expects a control refnum of type Slide(Int32), you can wire a control reference of type Slide(Int32), Slide(Int8), or Slide(DBL), but not of type Slide(Cluster of DBLs). Wiring in the Slide(Int8) or Slide(DBL) will result in type coercion (no error) and thus a coercion dot as these representations are being coerced to Int32. Wiring the Slide(Cluster of DBLs) will result in a type conflict (error) and thus a broken wire. This is because the Int8 and DBL are numerics like the Int32 and can thus be coerced to be of Int32 representation. The Cluster of DBLs however, is not a numeric, but a totally different data type. Therefore, a cluster being of different data type than the numeric will result in a type conflict if wired together. Strictly typed references are most beneficial when you know exactly what type of data you will be using.

http://zone.ni.com/devzone/cda/tut/p/id/3159

I have seen this help file for long time, and been confused by it for long time. I don't think strictly type refnum control can do type coercion. If I put a U8 Enum refnum control on subvi's front panel, I can't connect it with a U16 Enum refnum control.

I don't know if I am right. 

[steady]

Besides, I don't know what Slide(Cluster of DBLs) is. I can't generate such data type.

[altenbach]

What is an "enum refum control"? Can you attach a small VI containing the various controls?

---

@steady wrote:

Besides, I don't know what Slide(Cluster of DBLs) is. I can't generate such data type.

---

A slide control with multiple sliders is a cluster datatype. One cluster element per slider.

Just place a slide, right-click it...add slider. Voila!

[steady]

Altenbath,

I should have said "Enum control refnum" instead of "refnum control". I describe it step by step.

Create sub VI:

1, Put an Enumeration type control;

2, Right click the control, choose "Representation" as U16;

3, Creat a reference to the control; create a control from this reference; then this control is a "strictly type" control refnum;

4, Creat a subvi, using the control refnum as an input connector;

Create main VI:

1, Put an Enumeration type control;

2, Right click the control, choose "Representation" as U8;

3, Creat a reference to the control;

4, Call the subVi; connect above reference with subvi's control refnum input; the wire is broken.

[Ben]

enums have the strings as part of thier data types. The stirngs have to match up as well.

If you concider the example of a case structure (with no default) driven by the enum, how would LV handle the situation when the case got a bad value?

Crash? Maybe.

Ben

[altenbach]

What you are doing has nothing to do with "coercion", you get the same problem if both enums have the same representation but differ in the items.

[steady]

Thanks for attenstion from all above.

Yeah it is quite reasonable to check the items. I have tried several cases:

1, Both Enum's are empty; U8 and U16 can't be connected; but U8 and U8 can be connected;

2, Both Enum's have same items; same results as above one;

I am using LV8.5. I am guessing the "type coercion" applies to old version. But NI doesn't update help file.

[steady]

It looks like I am right........

[altenbach]

Right about what? You said so many things.... 😉

[steady]

Altenbach,

I mean "strctly type" control refnum is so "strict" that it distinguishes U16 from U8. You can't connect a U8 control reference with a U16 control refnum at least for LV8.5. But in before version like LV6, it seems ok.