LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Unnamed controls and Unbundle by Name

There was a discussion awhile ago about unnamed controls and event structures.  While events will recognize unnamed controls, I realized today that "Unbundle by name" does not. Just thought I'd share.

unbundle.png

 

Normal unbundle does show all 3 controls.  Unbundle by name doesn't even recognize that there is a third control (boolean) in the cluster.

0 Kudos
Message 1 of 7
(2,788 Views)

Yup.  This one doesn't get me very often but several times I was confused as to where my data went.

 

I guess the only alternative is that NI could have an item there like <Unnamed Data 1> or something but the best bet is to probaby just name all of your data.  If you do have some data that isn't named and you want it to be you could use the Coerce To Type and have the type terminal be the same data type but have a label.  Attached is an example.

Message 2 of 7
(2,768 Views)

For controls the solution is easy:  Name them.  It came up for me today because I had added the iteration index in to my cluster and built a conditional array. When it came time to unbundle and use that index, I was ... confused.

0 Kudos
Message 3 of 7
(2,760 Views)

@Hooovahh wrote:

 

I guess the only alternative is that NI could have an item there like <Unnamed Data 1> or something but the best bet is to probaby just name all of your data.  


Excellent idea. That sounds like something that should go on the idea exchange. LV already names <untitled 1.vi> vis. Why not data?

PaulG.

LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
0 Kudos
Message 4 of 7
(2,751 Views)

@PaulG. wrote:

@Hooovahh wrote:

 

I guess the only alternative is that NI could have an item there like <Unnamed Data 1> or something but the best bet is to probaby just name all of your data.  


Excellent idea. That sounds like something that should go on the idea exchange. LV already names <untitled 1.vi> vis. Why not data?


A dangerous task that idea.  it would require a mechanism to create a non-null caption if label is "null" without overwriting any existing intentionally "null" captions which would need to remain "null" and have the same problem with unbundle by name.

 

Forcing the clester members to have a name by providing the cluster definition is fairly easy.

!1.png

Interesting tidbit: even though the wires are all error color the unbundle still needs a caption or lable


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 7
(2,743 Views)

@JÞB wrote:
Forcing the clester members to have a name by providing the cluster definition is fairly easy.

!1.png

Interesting tidbit: even though the wires are all error color the unbundle still needs a caption or lable


I heard in the 2009 era, error wires became something more then just a cluster of 3 elements.  Things like the new Merge Errors couldn't work before this change (again I just heard from a non NI employee this).  I'm guessing NI then needed to add code to detect if a particular cluster was a special cluster and is now an Error type.

 

I'm guessing what's going on here is the NI code detecting if a cluster is an error is simply looking for the elements and the order, and not the labels.  The code I described can be seen here and notice it doesn't look at the labels either.

0 Kudos
Message 6 of 7
(2,721 Views)

I don't see how giving them an internal "name" for clusters would cause any more problems than giving them an internal "name" for event structures - which has been done.  Inside an event structure, unnamed controls are listed as #0, #1, etc.

0 Kudos
Message 7 of 7
(2,717 Views)