Hiding Property Nodes on the Block Diagram

[BowenM]

I historically took the approach Raven described as well.  However, something I've started to do recently is make the subvi into a functional global. 

During initialize, I'll feed the cluster of references in (often a cluster of clusters, or a cluster of reference arrays to group them together in a meaningful way), and then have a series of commands to the FGV where I can disable / enable groups of controls easily from anywhere in the program.

Some examples of when I use this:

FGV Command: Disable Start Logging. Used when either data acq is not running OR when logging is already started.

FGV Command: Enable Start Logging. Used when either data acq starts OR when logging stops.

... etc.

[billko]

---

@johntrich1971 wrote:

---

@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.

---

Ahh, yes - completely understood.  🙂

[billko]

---

@BowenM wrote:

I historically took the approach Raven described as well.  However, something I've started to do recently is make the subvi into a functional global. 

During initialize, I'll feed the cluster of references in (often a cluster of clusters, or a cluster of reference arrays to group them together in a meaningful way), and then have a series of commands to the FGV where I can disable / enable groups of controls easily from anywhere in the program.

Some examples of when I use this:

FGV Command: Disable Start Logging. Used when either data acq is not running OR when logging is already started.

FGV Command: Enable Start Logging. Used when either data acq starts OR when logging stops.

... etc.

---

I like this expansion!

[RavensFan]

---

---

@johntrich1971 wrote:

---

@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.

---

---

I'll do a combination JohnTRich's and MarkBowen's ideas.

I have a subVI that behaves has a functional global variable.  Two Inputs (a VI reference for this VI, and an enum command (Initialize, Default)).  One output, The master cluster of all references.

At beginning of programming I wire ThisVI and Initialize Enum into the functional global variable.  The subVI uses the subVI's for getting references by name along with a list of names of controls I want to build.  Then it builds up the cluster of whatever typedef shape I wanted to be based on those references.  Stores that cluster in the uninitialized shift register.

Whenever I want any references, in main VI, subVI's, wherever,   I drop down this FGV without any inputs.  The default case just outputs the cluster.  Then the VI, subVI, unbundles whichever references it wants to work on.

Whenever I want to work with a new control, I had it to the initialize code and bundle it in.  Then I go through a few steps to update the typedef with the new reference added to the structure.

The top level VI is much cleaner.  All the real estate needed to get references and bundle them are hidden in the initialize case of the FGV which is executed once at the beginning of the main VI.