Get Owning Pane of Control VI

[Darren]

Introduction

Strangely, there's no easy way to determine the Pane that owns a given control.  This VI should do just that, handling all corner cases that I could think of.

Steps to Complete

This VI works in LabVIEW 8.5 and later.  Pass in a control reference, and the VI will return a reference to the Pane that owns that control.

[Baptiste_CA]

Darren,

why do you have a sequence structure in your vi? What happens if the structure is removed? Is there a risk that the loop exits before the Close references node executes and closes the controls references?

[Darren]

The Search 1D Array function will only work if all the references in its array are valid.  If I didn't have the Flat Sequence Structure in there to enforce data flow, there is the possibility that the array of references would be closed before the Search 1D Array executes.  With the code as I have written it, the array will always be searched before it is closed.

-D

[davidc10]

thanks

[wirebirdlabs]

Will this VI not work in an executable since it contains Scripting nodes? Thanks in advance for the response.

[Darren]

That's right, Jack.  This VI will only work in the IDE, and will probably either no-op or (more likely) generate an error when run from within an EXE.

-D

[wirebirdlabs]

Bummer. Anyone reading: vote for Add Control.OwningPane. In the meantime, continue the 1D array searches of Panes[] and Controls[] monkey business.

[Nitin_T]

FYI: I built an exe (using the above example VI) and didn't have any issues running it. Was returning the right pane for the control I selected.

[wiebe@CARYA]

Isn't the "Traverse for GObjects" an expensive way to get the panes of a VI? FrontPanel.Panes seems (a lot) faster. Same for Pane.Controls[]?

Now it's Monday morning, so I might miss something here...

[Jim_Kring]

@wiebe wrote:

Isn't the "Traverse for GObjects" an expensive way to get the panes of a VI? FrontPanel.Panes seems (a lot) faster. Same for Pane.Controls[]?

---

I think Pane.Controls[ ] doesn't include controls nested inside of Clusters and Tab Controls, whereas Traverse for GObjects will handle recursing into those nicely, which makes it a more general solution.

[Jim_Kring]

Here's a possible performance improvement that speeds up execution when it is called in a loop with a static control reference wired in -- meaning, if the input control reference doesn't change, then it uses a cached Pane reference, rather than looking it up again. Note: This VI is reentrant so that if it's called in multiple places each instance can have its own cached pane reference.

Get Owning Pane of Control.vi (Cache Pane Reference)

[wiebe@CARYA]

@wiebe wrote:

Isn't the "Traverse for GObjects" an expensive way to get the panes of a VI? FrontPanel.Panes seems (a lot) faster. Same for Pane.Controls[]?

I think Pane.Controls[ ] doesn't include controls nested inside of Clusters and Tab Controls, whereas Traverse for GObjects will handle recursing into those nicely, which makes it a more general solution.

Ah, that's true.

But since LV2012 we can simply use the Owning Pane property, right?