LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Scripting Express VIs

Solved!
Go to solution

With scripting, is there any way yo determine whether a SubVI is an Express VI?

Is there any way to script the conversion of an Express VI to a standard SubVI?

ev.png

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 8
(204 Views)
Solution
Accepted by paul_cardinale

You can read the Is Instance property of the VI to see if it is an Express VI:

 

is_instance.png

 

As for programmatically converting to a subVI, there is a private method for that. I've attached a password-protected VI (saved in LabVIEW 2014) that wraps the private method. Note that use of this method is not officially supported by NI.

 

 

DNatt, NI
Message 2 of 8
(168 Views)

@Darren wrote:

You can read the Is Instance property of the VI to see if it is an Express VI:

 

is_instance.png

 

As for programmatically converting to a subVI, there is a private method for that. I've attached a password-protected VI (saved in LabVIEW 2014) that wraps the private method. Note that use of this method is not officially supported by NI.

 

 


Thank you.

But I hate your icon.  Try this: ic.png.

Also, shouldn't you have closed the VI reference?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 8
(156 Views)

Eh, my text-based icon is more readable. 😉

 

Also, what are you doing looking at that diagram?

 

Also, I wasn't sure if that private method would invalidate or otherwise mess with the VI reference, so I didn't close it. I don't think it matters much either way.

DNatt, NI
0 Kudos
Message 4 of 8
(147 Views)

@Darren wrote:

Eh, my text-based icon is more readable. 😉

 

Also, what are you doing looking at that diagram?

 

Also, I wasn't sure if that private method would invalidate or otherwise mess with the VI reference, so I didn't close it. I don't think it matters much either way.


I hate looking at a block diagram that's got a bunch of white icons with little black squiggles in them.  At a glance, they're harder to differentiate.

I usually look at block diagrams (even when I'm not supposed to).

Also, I was under the impression that any non-GObject reference coming out of a property node should be explicitly closed.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 8
(142 Views)

@paul_cardinale wrote:

Also, I was under the impression that any non-GObject reference coming out of a property node should be explicitly closed.


Yes, that's usually true. In this case, we're replacing an instance VI with another VI, and I figured there was a good chance that the original instance VI reference would no longer be valid. It wouldn't hurt to close the VI reference, but I'd probably ignore its error output.

DNatt, NI
0 Kudos
Message 6 of 8
(136 Views)

@Darren wrote:

@paul_cardinale wrote:

Also, I was under the impression that any non-GObject reference coming out of a property node should be explicitly closed.


Yes, that's usually true. In this case, we're replacing an instance VI with another VI, and I figured there was a good chance that the original instance VI reference would no longer be valid. It wouldn't hurt to close the VI reference, but I'd probably ignore its error output.


Is that also true for application references?  When I get an app ref from a property, should I explicitly close it?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 8
(77 Views)

@paul_cardinale wrote:


Is that also true for application references?  When I get an app ref from a property, should I explicitly close it?


I discuss the topic of "which references to close" in my Brainless LabVIEW presentation. Here are the relevant slides:

 

always.pngnever.png

DNatt, NI
Message 8 of 8
(73 Views)