Coercion dot on LabVIEW Object

[Francois Normandin]

I feel naughty every time I see a coercion dot on my block diagrams and try to get rid of them as often as possible. But there's one case for which I don't understand why there's a coercion dot in the first place: wiring an object to its ultimate ancestor, the LabVIEW object.

A child wired to its parent class method will not show the dot, but wiring any object to the LV object terminal will.

Would there be an instance when this is necessary to notify us we're about to use the inheritance in a potentially unintended way?

[jgcode]

I feel naughty every time I see a coercion dot on my block diagrams and try to get rid of them as often as possible. But there's one case for which I don't understand why there's a coercion dot in the first place: wiring an object to its ultimate ancestor, the LabVIEW object.

A child wired to its parent class method will not show the dot, but wiring any object to the LV object terminal will.

Would there be an instance when this is necessary to notify us we're about to use the inheritance in a potentially unintended way?

Hi François

Nothing sinister here, if the LabVIEW data member VI (dynamic or static) has its class input wired to it's class output then you will not see a coercion.

Otherwise you will see a coercion.

AQ made a post about this relationship recently in explaining some checking that occurs - I can't find the link yet - sorry! .

But you may find it an interesting read!

[Francois Normandin]

I'll be damned.

If you can find that document, I'll be sure to read it. I remember seing something about that a while back but can't find it either. I'll start by browsing AQ's posts...

Thanks Jon,

[jgcode]

I'll be damned.

If you can find that document, I'll be sure to read it. I remember seing something about that a while back but can't find it either. I'll start by browsing AQ's posts...

Thanks Jon,

Haha got it!

Thralled - thats the word I was having trouble remembering

[Aristos Queue]

Initially we did it because we followed the same rules as VI Server, which does show coercion dots for the hierarchy of control refnums (wire a Knob refnum wire to a Control Refnum terminal and you'll get a coercion dot). Later we figured out that it helped you recognize whether or not automatic downcasting was operating or not. But I'm still in the camp that wishes we had different colors of coercion dots for different cases.

[Aristos Queue]

AQ made a post about this relationship recently in explaining some checking that occurs - I can't find the link yet - sorry! .

To be clear: the upcast coercion dot has no effect at runtime. It is not the same type of performance penalty that the coercion dot from int to double represents. We've talked about wanting two different coercion dots, but that's hard to provide since red appears to be the only color that most people can see in that small a space and there's no way to put a different pattern when you only have 6 pixels. So all the coercion dots look the same.

Typedef to not-typedef-but-still-same-type (and vice versa) is another coercion that has no runtime performance penalty.

[jgcode]

Typedef to not-typedef-but-still-same-type (and vice versa) is another coercion that has no runtime performance penalty.

I have always wondered about this - cool.