LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a way to determine if a vi is running in a subpanel?

Sure, please see attachment. In order to get the Native window node you have add some keys to your Labview.ini file (in the same folder as Labview.exe)

 

These keys are the ones that I have:

 

SuperPrivateScriptingFeatureVisible=True
SuperPrivateSpecialStuff=TRUE
SuperSecretPrivateSpecialStuff=True

;Enables selecting an individual cell, highlighting it, vertically centering text. Removing spaces when there is no glyph.
SuperSecretListboxStuff=True
SuperSecretCLAFeatures=True

;Adds a whole bunch of additional options to the context menu for a plot legend
AdvancedPlotLegendMenu=True

;Adds "Persist State To Edit Mode" and "Destroy And Recreate When Run" to the Advanced submenu of an ActiveX container
ActiveXMoreContainerOptions=True
TotallySecretAndPrivateMSNCompanionDiagram=True

;adds an additional context menu option to the While loop; not sure what the different options do
whileLoopSharedCloneOptions=True

;enables the creation of generic VI's (danger!) by right-clicking a control or indicator and selecting "Generic"
GenericsAreGo=True

;Adds a new context menu item to constants based on strict typedefs called Act as Strict Typedef Constant. Function unknown.
EnableStrictTypedefConstantConfiguration=True

;Adds additional context menu items to custom control parts that configure how they scale with the control. Apparently some other hidden menu items are added somewhere too. (Thanks, hooovahh and Christina Rogers!)
enableSecretPopups=True

;Adds a new menu item to Property and Invoke nodes labeled "Run At Any Loop". When selected, the node turns brown as if a private property or method was selected, even if none are. Function unknown.
showRunAtAnyLoopMenuItem=True

;Adds some additional memory-related information to the context help window when you hover over a wire. Also adds a context menu item to wires called Select InPlace Signals, which likely selects wires that share a memory address. Seems like it could actually be pretty useful for optimization!
ShowWireAddressMode=True

;Adds a context menu option to the Simulation structure called "Show Companion Diagram", which toggles showing what looks like a "behind-the-scenes" block diagram for the simulation.
SimShowCompanionDiag=True

;Shows hidden library items. (big surprise there!) So far I've only seen changes when editing a statechart library, but it seems most of the items in a statechart library are hidden, so it reveals a lot.
ShowHiddenLibraryItems=True

Message 11 of 32
(2,132 Views)

And now for the bonus question:

In a project with tons of VIs, some reentrant and dynamically started, how to get the reference of the subpanel a VI is in?

 

This turns out to be pretty hard. However, this idea (that would be a lifesaver) is probably not going to happen. But feel free to comment or kudo.

0 Kudos
Message 12 of 32
(2,092 Views)

Normally you don't have a way of knowing that information.

 

If you want a generic solution, in the sense of an independent VI which you can call in any project, on a VI reference, to tell you in which subpanel that VI is, you would need to get a refnum to all VIs in that application instance and then recursively go through their front panel controls and each time you encounter a subpanel check the reference of the inserted VI. This is a brute force, unelegant solution which I would not implement.

 

If you need a one time solution, just in a particular project, you can have each VI which owns a subpanel register the refnum of that subpanel into a project global variable. Then from your VI which resides in a subpanel, you go to that global variable and get the inserted VI refnum from each subpanel and check if it eqauls "This VI" refnum.

 

How does that sound?

0 Kudos
Message 13 of 32
(2,087 Views)

@Lexandros wrote:

How does that sound?


Horrible.

 

That's why I proposed the idea on the idea exchange.

0 Kudos
Message 14 of 32
(2,084 Views)

wiebe@CARYA wrote:

And now for the bonus question:

In a project with tons of VIs, some reentrant and dynamically started, how to get the reference of the subpanel a VI is in?

 

This turns out to be pretty hard. However, this idea (that would be a lifesaver) is probably not going to happen. But feel free to comment or kudo.


I'd probably make a "Insert into Panel"-vi that stores the ref (in a FGV or as Variant or the new map) and inserts into panel. 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 32
(2,074 Views)

@Yamaeda wrote:

wiebe@CARYA wrote:

And now for the bonus question:

In a project with tons of VIs, some reentrant and dynamically started, how to get the reference of the subpanel a VI is in?

 

This turns out to be pretty hard. However, this idea (that would be a lifesaver) is probably not going to happen. But feel free to comment or kudo.


I'd probably make a "Insert into Panel"-vi that stores the ref (in a FGV or as Variant or the new map) and inserts into panel. 

/Y


Sometimes you just want to make a (reusable) library or tool that works. Regardless of a VI is inside a subpanel or not. In those cases, making the user provide a (potentially recursive) subpanel reference is just annoying**.

 

In normal programming, I always provide a subpanel to a sub VI, so the sub VI can insert\remove itself. This is (or used to be) the only reliable way to make LabVIEW not crash when recursively inserting clones in subpanels. Closing a clone with a subpanel with a clone in it used to be very unreliable. Perhaps it still is.

 

** I had to make a test framework for my application. A very simple function was to click a button. Of course the button was latch when released. So no event signaling...  Next best ting is to simulate a click. But then you need a coordinate. Converting the coordinate of the button to screen coordinates requires a subpanel ref. So I traverse all VIs for subpanels. But there a clones. There's no way to get clone references... And so on (or in fact, that was is, but it was enough).

 

IMHO, it would be so much easier if a VI had a reference of the panel it's in. But apparently it's some kind of evil...

0 Kudos
Message 16 of 32
(2,072 Views)

wiebe@CARYA wrote:

@Yamaeda wrote:

wiebe@CARYA wrote:

And now for the bonus question:

In a project with tons of VIs, some reentrant and dynamically started, how to get the reference of the subpanel a VI is in?

 

This turns out to be pretty hard. However, this idea (that would be a lifesaver) is probably not going to happen. But feel free to comment or kudo.


I'd probably make a "Insert into Panel"-vi that stores the ref (in a FGV or as Variant or the new map) and inserts into panel. 

/Y


Sometimes you just want to make a (reusable) library or tool that works. Regardless of a VI is inside a subpanel or not. In those cases, making the user provide a (potentially recursive) subpanel reference is just annoying**.

 

In normal programming, I always provide a subpanel to a sub VI, so the sub VI can insert\remove itself. This is (or used to be) the only reliable way to make LabVIEW not crash when recursively inserting clones in subpanels. Closing a clone with a subpanel with a clone in it used to be very unreliable. Perhaps it still is.

 

** I had to make a test framework for my application. A very simple function was to click a button. Of course the button was latch when released. So no event signaling...  Next best ting is to simulate a click. But then you need a coordinate. Converting the coordinate of the button to screen coordinates requires a subpanel ref. So I traverse all VIs for subpanels. But there a clones. There's no way to get clone references... And so on (or in fact, that was is, but it was enough).

 

IMHO, it would be so much easier if a VI had a reference of the panel it's in. But apparently it's some kind of evil...


Yeah, sending the ref to the VI is a simple solution that'd work. Storing it would make it accessible from other places, for good and bad. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 17 of 32
(2,067 Views)

It's a bit hacky, but an alternative would be to write "Front Panel Window" -> "Behavior" to its current value and check for an error.  This property is read-only if it's running as a subpanel.

 

_carl_0-1608742067014.png

 

Message 18 of 32
(1,837 Views)

@_carl wrote:

It's a bit hacky, but an alternative would be to write "Front Panel Window" -> "Behavior" to its current value and check for an error.  This property is read-only if it's running as a subpanel.

 

_carl_0-1608742067014.png

 


VI.Front Panel.Native Window is 0 if it's in a subpanel or closed.

VI.Front Panel.Window Interface is 0 if it's closed.

 

That logic can be used to determine if the VI is in a subpanel.

 

So much easier that a property node!

Message 19 of 32
(1,816 Views)

wiebe@CARYA wrote:

@_carl wrote:

It's a bit hacky, but an alternative would be to write "Front Panel Window" -> "Behavior" to its current value and check for an error.  This property is read-only if it's running as a subpanel.

 

_carl_0-1608742067014.png

 


VI.Front Panel.Native Window is 0 if it's in a subpanel or closed.

VI.Front Panel.Window Interface is 0 if it's closed.

 

That logic can be used to determine if the VI is in a subpanel.

 

So much easier that a property node!


Sure, except "Native Window" is not natively available (so not really easier). Previous comments in this thread indicate that one of a dozen or so keys need to be added to the LabVIEW.ini to make it available (but without an indication of which one it is).

0 Kudos
Message 20 of 32
(1,809 Views)