Coercion dots between typedef to non-typedef

[mthheitor]

Hello,

I've read some old topics about coercion dots between typedef & non-typedef, but I don't understood the solution quite well.

I don't understood how do I remove the typedef coercion dots efficiently.

In my VI, I use custom Controls to represent LEDs and 2D Array along my main and subVIs. If I change one of the standard .ctl, all instances have to change. So typedef is a requirement.

Look at one of my subVI:

I'm receiving data from a PLC with OPC-Read function, this data is organized inside the subvi "Barra Status 0", and the result is shown on my custom Boolean Control. I want to remove these coercion dots...

But the only option that I could see was to do a "Case Structure",something like this:

But it really doesn't look like good practice. (I'm using three different custom boolenas in this snippet)

The second coercion dot that is annoying me is the coercion dot in the 2D Array. Because I transfer the data between subVIs with Notifiers/Queue, the typedef is good if the data needs to change its type (using typedef I don't need to manually change the constant on each Obtain Notifier/Queue). But again I have a coercion dot after the data read from OPC-DAQ

How can I remove these coercion dots?

[PeterFoerster]

Hi,

First off, good on you to consider coercion dots in that much detail! I wouldn't worry about them too much, because in this case it is just telling you that the types you wire to their targets are not of the same type defined datatype. This can be important for some datatypes, but in your case I wouldn't worry about the values being incorrect since you connect boolean to boolean and double[][] to double[][].

Since you have an array of standard booleans that you want to write to different typedefined booleans, you could split the array into the 3 groups and type cast each group to an array of that typedef. The type cast function with a constant of Array of the typedef wired to the type input can do this for you. I wouldn't bother.

Is there a reason the booleans are all type defined?

As for the 2D array of double, again I'd ask, why is it type defined in one place only? You have a type def wired to the obtain queue, but not to the shift register and m_matrizLeiturasAtualizada is also not of that type. Either change all of them to the same type def or remove the one typedef you used.

[Bob_Schor]

The Rule for Arrays is that every element must be the same Type.  In particular, if you have an Array of Booleans (let's make them LED Indicators), they must all be the same type.  In particular, you cannot mix a Boolean LED with On/Off colors of bright and dark Green with an LED whose colors are bright and dark Red -- they are all "greens" or all "reds".

So when you try to "stuff" an Array with Booleans associated with different TypeDefs, you cannot do that!  You Array will be an "Array of <some single TypeDef>", and every element you wire into it must either be of that Type or be coerced to that Type.

There are several "work-arounds", depending on what you want to accomplish.

• Use a Cluster instead of an Array -- every element of a Cluster can be a different Type, in particular, every element can be a different TypeDef'ed Boolean.
• Create N Typedef'ed Booleans, and create an array of References to those Booleans.  Now all of the Booleans can have different Types as the Array elements are all "Reference to Boolean".
• Use an N-Element Radio Button (this restricts you to having at most one of the Booleans "on" at a time.

Bob Schor

[Yamaeda]

Tip 1A is ofcourse to use the typedef everywhere, but there are still some places where you'll run into coercion. In many cases they can be ignored (like you boolean array to the type def'd indicators, we know they are both booleans), but if you really want to remove all coercion dots, you can Type Cast from e.g. a normal boolean to a type def'd one.

/Y

[wiebe@CARYA]

What's the point of making a Boolean or double a type def?

I know, it might change, but is a Boolean ever going to change to for instance an integer? I can see a double change to a single for instance, but I'd still consider not making it a type def.

[billko]

---

wiebe@CARYA wrote:

What's the point of making a Boolean or double a type def?

I know, it might change, but is a Boolean ever going to change to for instance an integer? I can see a double change to a single for instance, but I'd still consider not making it a type def.

---

I've had requirements change so that what was once a Boolean value became an integer.

[altenbach · Accepted solution]

There is absolutely no need to remove these coercion dots. there is no conversion or new buffer allocation taking place, so they don't cost you anything. See also this discusssion and the discussions for this idea.

[PeterFoerster]

---

@billko wrote:
I've had requirements change so that what was once a Boolean value became an integer.

---

So, how does that work? You have a boolean typedef that displays the result fo some boolean operation. Suddenly your requirements change and you change the typedef to a numeric. This wouldn't change your code, would it?

I guess the advantage of typedefs here would be that everything breaks and you'd get reminders where to fix it.

[billko]

---

@PeterFoerster wrote:

---

@billko wrote:
I've had requirements change so that what was once a Boolean value became an integer.

---

So, how does that work? You have a boolean typedef that displays the result fo some boolean operation. Suddenly your requirements change and you change the typedef to a numeric. This wouldn't change your code, would it?

I guess the advantage of typedefs here would be that everything breaks and you'd get reminders where to fix it.

---

That's exactly the advantage here.  You'll know every single instance you need to go fix.*  That is a BIG advantage.

*If the changes are more subtle (let's say, adding an item to an enum), there may be some places where you'll have to find them yourself - but careful programming eliminates most of these instances.

[wiebe@CARYA]

So to summarize:

1) Don't worry about the coercion dots, they don't do any harm

2) Make the indicators type defs too, no coercion dots.

3) Don't make the type defs, , no coercion dots.

Can we conclude that what works in which situation is going to depend on taste mostly?