LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
SimpiC

Creating a bundled reference typdef and access nodes

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

I'm a relative newcomer to LabVIEW and one thing I almost always do when I start a project is take a reference to all of my FP controls and then bundle them up in some sort of order, create a constant and typedef them so that I can use a single wire to pass the references to all my sub-vi's.  

 

There are some limitations to this process and one of them is that any changes to your front panel result in you having to rebuild the typedef from scratch which can be quite laborious.  Another is that extracting a value or property from the wire can involved quite a few actions (unbundle by name, create a property node, unbundle again....twice etc.) but LabVIEW knows exactly what's in the wire.

 

I'm convinced that I could script the process for creating what I call a 'referential typedef' but updating an already existing typedef is a bit more difficult.  I'd also like to build a single configurable access node that allows the operator to extract the specific data element the operator needs as a property attached to a connection pin rather than having to wire a string of unbundles and property nodes.

 

I'd like to see if other users do similar things to me (I suspect they do as a CLA taught me the process) and if they do would NI look at building these elements into a future version of LabVIEW?

4 Comments
SteenSchmidt
Trusted Enthusiast

Why do you want access to all of your Top-Level VI's controls and indicators in all of your subVIs? And does your workflow include bundling up all of your subVI's control refnums and pass those to the next level of subVIs as well, or is it only the Top-Level VI control refnums that gets pushed down into the hierarchy?

 

I find it quite rare to need access to controls and indicators by refnum, at any level in my hierarchy, due to both the performance issues involved and since there are better ways to encapsulate code. I'm not saying there aren't exceptions, I'm just saying I'm personally very far from needing a built-in solution to this.

 

Cheers,

Steen (also a CLA Smiley Happy)

CLA, CTA, CLED & LabVIEW Champion
crossrulz
Knight of NI

I ran into a situation where I needed a reference for all of my controls.  So I made a VI to get them for me.  It turned into a reentrant VI in order to get the controls inside of tab controls.  But it wasn't that complicated.


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
SimpiC
Member

Thank you for the feedback Steen.  

 

In all of the applications I've built to date I've had to programmatically change the look of feel of a top level control or indicator during run-time.  Disabling buttons and the like.  Hence the practise I've been using.

 

It's only the top level controls that I need to do this to and to my understanding using a reference to the control and a property node is the most effective way to access and modify a property from within a sub-vi so from a cohesion point of view I see it as being the best way to handle the task.

 

I'm interested in how you would approach this problem, if you had a tab control on the front panel with multiple controls on the pages, some in clusters, maybe some in an array, how would you change their properties whilst at the same time not allowing the top level VI to become over-run with wires?

 

Your insight would be much appreciated.

 

SimpiC (just a CLAD):smileywink:

 

 

Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined.