LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

coercion dot digital numeric indicator

Solved!
Go to solution

Using trial version of LabVIEW 2013 64-bit.

 

I have a U32 digital numeric indicator on the front panel.

I am passing a reference of it to a subVI. The subVI has a control that is VI Server Class -> Generic -> GObject -> Control -> Numeric -> Digital

On the main VI, there is a coercion dot.

 

Not sure what LabVIEW does not like and what I should be doing to remove the coercion dot.

 

0 Kudos
Message 1 of 5
(3,019 Views)

What is the data type the property node want?  The context help should tell you.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 5
(3,013 Views)

@crossrulz wrote:

What is the data type the property node want?  The context help should tell you.


I am not sure I understand what you mean.

 

I am not using property nodes.

 

The subVI input is a refnum. The main VI has a digital numeric indicator of U32.

0 Kudos
Message 3 of 5
(2,999 Views)
Solution
Accepted by nyc_(is_out_of_here)

Ok, I see what you are saying now.  You get a coercion from the reference, not from a value property inside of the subVI.

 

This seems like a difference between a Strict Typed reference and a normal digital control reference.  You can make the reference input a strict type by right-clicking on it and select to show the control.  Then drag a control into it (preferably one just like what you are trying to control).  But this will make the VI specific to a U32 digital control.  Not always desirable.  As you have it now, I think it just recasts the reference.  I personally wouldn't worry about it.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 5
(2,991 Views)
Solution
Accepted by nyc_(is_out_of_here)

@crossrulz wrote:

 I personally wouldn't worry about it.


In this case I wouldn't worry about it either.  Coercion doesn't always mean bad things happen like lost data.  Some times it is just a way to let you know that the data is becoming a different type.  As a developer it is important to know when coercion can result is lost data.  When coercing a reference to a less specific referance there is no data lost, but there maybe less functionality in the property/invoke nodes used.

 

Lets say you had a ComboBox control on the front panel.  This behaves like a string but has some added functionality.  Now lets say your subVI accepted a reference to a string control as an input.  Wiring the ComboBox reference to it will result in a coercion dot but it will run.  Is there any data lost?  Well no, you can still read the Value property node in the subVI and all will work just fine.  But there are other properties for ComboBoxes that don't exist for normal strings.  Things like setting what options the ComboBox has when you click it.  So in the subVI these properties won't exist because they don't exist for a string, only a ComboBox.  Now you could use the To More Specific function and cast it back to a ComboBox but the input is a string, and someone could use the subVI passing in a string not a ComboBox and then an error would occur at the more specific function.

 

TLDR, coercions don't always mean the world is ending and it is up to the developer to know when a coercion is okay.

Message 5 of 5
(2,982 Views)