coersion dots and Strict Type Def

[nyc_(is_out_of_here)]

I have created a Strict Type Def cluster with boolean indicators.

I am unbundling the cluster and wiring some of the unbundled outputs to a subVI that I created. This subVIs input is connected directly to the Selector input of a the Append True/False String function.

This works, but I am trying understand why there is a coersion dot at the when the output from the cluster is wired to the subVI. Is the reason because the cluster is a Strict Type Def?

If I wire the unbundled output of a regular cluster then no coersion dots appear.

[ThiCop]

Hello nyc,

Can you post an example VI and cluster to illustrate the issue?

This way I can try to reproduce your issue.

Thanks in advance!

[Ben · Accepted solution]

Turn on your help window,

Switch to the wire tool,

Float over the wires and compare what you see in the help window.

I suspect type-def to non-typed def is being enunciated by the cooecion dot.

set rant = True

That scenario is one of the reasons I freak-out over the rumour that coercion dots imply a buffer copy. They do NOT. LV is only telling you it is doing something to the data representation and want to let you know about it.

Done ranting,

Ben

[nyc_(is_out_of_here)]

---

@ThiCop wrote:

Hello nyc,

Can you post an example VI and cluster to illustrate the issue?

This way I can try to reproduce your issue.

Thanks in advance!

---

I have attached the Strict Type Def cluster control, the subVI, and the main VI.

Edit: I had forgotten that the boolean controls in the cluster were Strict Type Def booleans. My bad.

As an experiment when I disconnected the boolean controls from the type def, the coersion dots went away.

[nyc_(is_out_of_here)]

---

@Ben wrote:

Turn on your help window,

Switch to the wire tool,

Float over the wires and compare what you see in the help window.

I suspect type-def to non-typed def is being enunciated by the cooecion dot.

set rant = True

That scenario is one of the reasons I freak-out over the rumour that coercion dots imply a buffer copy. They do NOT. LV is only telling you it is doing something to the data representation and want to let you know about it.

Done ranting,

Ben

---

 I had forgotten that I had made the boolean controls in the Strict Type Def cluster to be Strict Type Def boolean controls. Once I disconnected them from the Type Def, the coersion dots went away.

[ThiCop]

But a coercion dot can indicate a buffer copy....

Did I get you freaked-out ? 😉

This is indeed a very common misconception...

Red dots seem to make some people panic... 🙂

[Ben]

---

@ThiCop wrote:

But a coercion dot can indicate a buffer copy....

Did I get you freaked-out ? 😉

This is indeed a very common misconception...

Red dots seem to make some people panic... 🙂

---

as CAN a wire fork but there are no red dots there. so again

"Coercion is not equal to buffer copy"

The only valid way of seeing if a buffer is copied is;

Tools >>> Profile >>> Show Buffer Allocations

Show me a situation where there is a buffer copy and SHow BUffers.. does not show the extra buffer and I'll get a SR and CAR filed ASAP.

Ben

[ThiCop]

Hello Ben,

That's completely true!

I just was trying to get someone to write your statement (about Tools >>> Profile >>> Show Buffer Allocations), without the message coming from an AE 🙂

[Ben]

---

@ThiCop wrote:

Hello Ben,

That's completely true!

I just was trying to get someone to write your statement (about Tools >>> Profile >>> Show Buffer Allocations), without the message coming from an AE 🙂

---

It not nice to tease the bear. He has a signature and knows how to use it.

Ben