>>NARRATOR: In our last episode!
We learned about intuitivity and disabling and enabling front panel objects with property
nodes. As we see here, these front panel objects being enabled or disabled with these property
nodes. At the end I asked if there exists an easy way to modularize what I’ve done
and access the same disable property on all these objects without creating separate property
nodes for each object each time I enable and disable. That’s what we really want and
that’s what we’ll do now. First we’ll look at how we previously accessed
the disable property: through these implicitly linked property nodes. Why are they called
that? To differentiate them from explicitly linked property nodes. Well what’s that?
I can create an explicitly linked property node by simply pulling up a generic property
node, this property node can display the properties of any object, it just needs to be pointed
to that object. We do that by creating a reference to an object. Let’s do that. We’ll copy
these controls to a new VI. Ctrl+N is a shortcut. I’ll right-click on Acquisition Rate and
choose create>>reference. Now, I’ll pull up that same generic property node and wire
the reference into the Reference input. Now I’ve exposed all the same properties of
the object with this explictly linked property node as I had with this implicitly linked
property node. The object is the Acquisition Rate Control. This property node is explicit
because I used this reference to explicitly point it to a particular object, and has the
added benefit of not needing a parental advisory. So why would we want to be so explicit? Let’s
examine. There are many reasons. A common reason is to have a single property node access
the same property of multiple objects. We have a perfect need for an explicitly linked
property node in our current Test.vi as these 3 implicitly linked property nodes here and
here are accessing the disabled property on 3 different front panel objects, these three.
If I want to use one generic property node on these other two objects I’ll need to
create references for those.
How can I have this same property node access these references? Simple, create an array
and auto-index it into a For Loop. Now choose the disabled property, change to
write, move this over, create a constant. Now if I pull up my front panel, and put this on highlight execution, I can
watch as one by one, I will disable each object. Take off highlight execution, enable them,
run them, they’re all enabled. Perfect. Going back to test.vi. I need to essentially
do the same thing in 2 places: disabling here and enabling here. Rather than make a copy
of this block of code twice, we know that this is a perfect case for a subVI. So I’ll
make this new VI into a subVI. To be able to control whether I enable or disable, I’ll
pull this constant outside of the loop and also create an error cluster going in and
Wire these back up, and disable indexing because I don’t want to have an array of error clusters.
This is the section I want to make into a subVI, so I’ll just select it and go to
Edit>>create SubVI. I’ll look at the block diagram of this new subVI. Let’s clean it
up with the block diagram cleanup. And I have this array of incoming references which corresponds
to an array of refnums or reference numbers on the front panel. This accepts an array
of incoming references from a calling VI. Let’s save this. I’ll call it disable
and give it a nice icon. There’s a glyph already waiting for me. Lovely. Now I’ll drop disable.vi in place of these
existing property nodes and connect everything. But first we’ll fix the connector pane, to the 4x2x2x4. Back on test.vi, I’ll make
this array of references. Simply copy this. Now I’ll see that my test.vi behaves exactly
as it did before. I can run it, edit these controls, when I click on run test, the test
is running and I can’t edit these controls, until the test is finished and they’ve been
re-enabled. Disable VI is now a very handy subVI to be able to use in future applications.
We’ll take a look at that in part B of this video.