From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Mixing types of references in array builder - Getting rid of red dots

Solved!
Go to solution

Hi,

I've used array builder to build an array of references of mixed types of controls.  I'm doing this to programmatically change multiple property nodes.  Any idea how to get rid of ugly red type conversion dots?  See attachment in LabView 2015.

0 Kudos
Message 1 of 11
(3,121 Views)

You can use To More Specific Class, but that will just do the same as the coercion dots.  Just leave the coercion dots.  It will actually be cleaner.


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 2 of 11
(3,112 Views)
Solution
Accepted by topic author andy_3141593

Those are coercion dots. To get rid of them you would need to use the "to more generic class" node, and convert them all to the most generic class out of your set of controls, maybe Generic >> GObject >> Control.

 

I personally see no reason to do this, as the code is more compact if you let this take place under the hood with the coercion dots.

Message 3 of 11
(3,110 Views)
Solution
Accepted by topic author andy_3141593

One way to avoid the red dots would be to change the references to the more generic control class reference using the To More Generic Class Function (found in the Application Control VIs and Functions menu) before you put all of the references into the Build Array function.  Connect the Target Class input in the Function to a Constant and then search for and select the Control class (Generic-->GObject-->Control).

Message 4 of 11
(3,105 Views)

(posting by phone, cannot look at your code)

 

You could also bundle them into a cluster instead ....

 

 

Message 5 of 11
(3,075 Views)

Hi All,

 

Thanks for the ideas.  The "To More Generic Class" with Generic >> GObject >> Control>> did the trick.  I went ahead with this solution just to learn and to have as an example of a complete solution.  You are right though, its cleaner just to leave the coersion dots.  I'm a C Code guy at heart and compilers generally complain about this sort of stuff.  By the way, I've got some background on Object Oriented code, but I'm a little rusty on Classes and really don't understand yet how they manifest themselves in LabView.  Anybody know of an article that they could point me to?  Thanks again!

0 Kudos
Message 6 of 11
(3,028 Views)

The word "class" is used in a couple different ways in LabVIEW. There are different types of front panel and block diagram objects which you are talking about here. A good way to learn more about this is to open help >> find examples and search for traverse. This will show you an example of traversing GObjects and finding their class names. These classes have properties and methods that you can interact with using property and invoke nodes respectively. 

 

There are also classes you can make yourself, which is what LabVIEW object orient programming often deals with. Classes are kind of a hybrid between LabVIEW libraries (.lib files) and clusters. They are like libraries in that they expect VIs to be under them and VIs belong to the class, and they are like a cluster because you define the cluster of data that is encapsulated by the class. Then they build on this with features like inheritance and different forms of dispatch. If you search for LVOOP you will find a lot of resources. I would start just by gaining an understanding and using libraries first, and this post by Ben should be very helpful. 

Message 7 of 11
(3,019 Views)

No problem.  Everybody made good suggestions on this subject.  One thing I noticed in your code is that your references aren't closed when you finish with them.  It's good coding practice in LV to do this.  You can use Close Reference in the Application Control menu.

0 Kudos
Message 8 of 11
(3,009 Views)

@gabe2327 wrote:

One thing I noticed in your code is that your references aren't closed when you finish with them.  It's good coding practice in LV to do this.  You can use Close Reference in the Application Control menu.


Not needed for control references.  In fact, the Close Reference will be a no-op for these.  For more details: Closing References in LabVIEW


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 9 of 11
(3,004 Views)

Thanks for the information and the reference to the document.


@crossrulz wrote:

@gabe2327 wrote:

One thing I noticed in your code is that your references aren't closed when you finish with them.  It's good coding practice in LV to do this.  You can use Close Reference in the Application Control menu.


Not needed for control references.  In fact, the Close Reference will be a no-op for these.  For more details: Closing References in LabVIEW


 

0 Kudos
Message 10 of 11
(2,993 Views)