Add a Control.OwningPane property

[TCPlomp]

When you want to find out where exactly a control is located on a computer screen (for some dark reason), there is a method for Panes called 'Convert Pane coordinates to Panel coordinates'.

However there is no easy way to get the owning pane of a control!

The propery 'Owner' of a control always returns the actual VI, not the pane.

Ton

[Darren]

I think it's weird that the Owner property of the Control class will return the Panel instead of the Pane that owns the control.  Unfortunately, I don't think we can change the property at this point without breaking an unknown amount of existing code out there.

I wrote a VI that handles this functionality in the most robust manner I can think of.  You can download it here.  Should I ship this VI with LabVIEW 2010, and if so, would it be a suitable implementation for this idea?

-D

[TCPlomp]

I don't think adding a VI in VI.lib is the best solution.

Isn't it possible to extend the VI server control-class with a new property?

Your code looks OK (mine was suffering from tabControl-o-fobia)

Ton

[AristosQueue (NI)]

> Isn't it possible to extend the VI server control-class with a new property?

Yes, it's possible, but due to time constraints, improbable. I think that's why Darren offered this alternate solution.

The only problem I see with Darren's solution is... where would you put it in the palettes? Just shipping it in vi.lib and saying "use this" would be yet an encouragement to use VIs not in the palettes. That would be something we have previously discouraged, and our failure to discourage it strongly has recently burned us badly, so I don't want to encourage it further. If it isn't going in the palettes, make it a separate download from ni.com, but don't ship it with LV.

[tst]

Something like this should definitely be shipped with LV, so that you can distribute code without having to worry about it.

I agree with Ton that having this as a new property (or as the old one with mutation code to fix old code) is considerably better, both from a cleanliness point of view and from the performance angle (I haven't tried Darren's VI, but if memory serves, doing something similar in one of the earlier 8.x versions was slow because of having to iterate over all the controls in all the panes until you get to the one you want).

To answer your question, however, this would probably belong somewhere in the Application Control palette.

[Darren]

AQ is right...there isn't time for someone to add the property in 2010, so I was offering to add it as a support subVI instead.  But like tst, I personally think these kinds of utilities are more easily accessible when shipped with LabVIEW, as opposed to being provided as separate downloads.  I would probably put the VI in vi.lib\VIServer, but not place it on the palettes.

But if y'all don't think my VI will be worthwhile enough to ship with LabVIEW 2010, I'll just leave it as an ni.com/community download.

-D

P.S. - tst, the VI uses a traversal to quickly pull the controls from each individual pane, then simply uses a Search 1D Array to figure out which pane owns that control.  It's pretty fast, although a built-in OwningPane property of the Control class would undoubtedly be faster.

[tst]

> ...quickly pull the controls from each individual pane

Quickly is relative. If you have a front panel with many controls, it may still take time. That said, it's been a while since I ran something like this, so it's quite possible the performance has improved. I would say that if there's no time to do it for this release but there is time to do it for the next one, then it should not be released as a shipping VI, but if there are no plans of working on it, then it's better to ship the VI.

Message Edited by tst on 05.12.2009 08:51 PM

[tst]

I ran a quick test (in 8.6) on a VI with 720 (don't ask) controls with multiple levels of nesting.

For more than 99% of them, the VI took between 85 and 100 ms to run (just over a minute for all of them). When running the same on a VI with just a few controls, it took around 35 ms for each control.

To be honest, I don't know if this is slow or not. I would have to check it against an actual use case, which I don't have at the moment.

[tst]

P.S. The slow part doesn't seem to come from the traversal itself, because I enumerated the controls using the same traversal VI and that took less than a second for the entire VI, so it probably comes from the lookup part.

[TCPlomp]

Well if it's the lookup it wouldn't be too hard to store them in a lookup table. So the time is only needed once.

[Charles_CLA]

Unfortunately it looks like this idea died. Any chance of getting this for a future release of LabVIEW?