Hiding Property Nodes on the Block Diagram

[KarlosAmigos]

Hi Everyone,

This is a fairly general question, but I am writing an application with many Front Panel controls and indicators, and I am using property nodes to set their initial state when the program starts up. In keeping with the single page design ethic for my main.vi, I am finding that my property nodes are taking up an increasing amount of real estate on the block diagram.
Is there a way to hide them? A sub-VI doesn't work as the nodes need to be on the main VI. Any suggestions, or should I be using a different method to set up the initial state of all my Front Panel elements?

Thanks,

Karl

[GerdW · Accepted solution]

Hi Karlos,

---

@KarlosAmigos wrote:

I am writing an application with many Front Panel controls and indicators, and I am using property nodes to set their initial state when the program starts up.

---

You may set (and save) default values in your controls so you don't need to use property nodes "when the program starts up"…

---

@KarlosAmigos wrote:

I am finding that my property nodes are taking up an increasing amount of real estate on the block diagram.
Is there a way to hide them? A sub-VI doesn't work as the nodes need to be on the main VI.

---

When there are a lot of controls then you surely need a lot of property nodes…

But no need to "hide them": use a subVI! Property nodes don't just "work on the main VI"!

All you need is a reference to the frontpanel of your main VI: then you are able to get all references of all frontpanel elements within your subVI.

---

@KarlosAmigos wrote:

a different method to set up the initial state of all my Front Panel elements?

---

As said before: set and save useful default values!

[KarlosAmigos]

Thanks GerdW,

Most of my nodes are to do with disabling various controls that aren't used until later, a few colours and stuff like that. The references did the trick and I ran them into a sub-VI as you suggested and hid all the property nodes in there.

The sub-VI looks a bit like a Coronavirus 😅 but a lot of space has been saved.

Thanks Again,

Karl

[RavensFan]

You can always bundle those references into a cluster so you only have one wire passing into the subVI.

[KarlosAmigos]

Oh man, that is so simple in its brilliance, I can't believe I didn't think to do that earlier as it grew and grew. Many Thanks!

[RavensFan]

One thing I recommend is that once you've bundled them up into a cluster, make a typedef control of that cluster.

Then go and use that to to a bundle by name and put that cluster control in the subVI.

That way if you ever find you need to add yet another reference, you can add it to the typedef, and it will be smoother transition when you bundle the new reference and the subVI control will update automatically without working harder to resolve type mismatches.

[johntrich1971]

You can actually do this with only 1 reference sent to your subvi. If you send a reference to the calling vi then you can get all of the control references inside the subvi.

[billko]

---

@RavensFan wrote:

One thing I recommend is that once you've bundled them up into a cluster, make a typedef control of that cluster.

Then go and use that to to a bundle by name and put that cluster control in the subVI.

That way if you ever find you need to add yet another reference, you can add it to the typedef, and it will be smoother transition when you bundle the new reference and the subVI control will update automatically without working harder to resolve type mismatches.

---

I learned this straight out of the LabVIEW Style Book.  It's great advice!

[billko]

---

@johntrich1971 wrote:

You can actually do this with only 1 reference sent to your subvi. If you send a reference to the calling vi then you can get all of the control references inside the subvi.

---

It's too high-maintenance for me.  The way Raven described is much more automatic.  You don't need to know what to cast it to, and you don't need to know what the name of the control is.  Just unbundle and go.

[johntrich1971]

---

@billko wrote:It's too high-maintenance for me.  The way Raven described is much more automatic.  You don't need to know what to cast it to, and you don't need to know what the name of the control is.  Just unbundle and go.

---

I like Raven's way as well, but it can still take up a lot of space on the block diagram if there are a LOT of controls that you have to make references to put into the cluster. Since the purpose is to initialize values you either have to have two cluster type definitions that you have to keep synchronized (one for the references and one for the initialization values, though the synchronization could be done by making each element be a cluster of reference and value) or you have to have a case for each control in the cluster. The type cast is actually not required for my approach, but I like to have the explicit type. Since the primary issue that Karlos Amigos was dealing with is real estate I was just offering this as an alternative to save even more real estate in the main.