Aerospace, Defense, & Government
Academic & Research
Benchtop Measurement and Test
Distributed Measurement and Control
Systems Engineering Software
You can request repair, schedule calibration, or get technical support. A valid service agreement may be required.
Provides support for NI data acquisition and signal conditioning devices.
Provides support for Ethernet, GPIB, serial, USB, and other types of instruments.
Provides support for NI GPIB controllers and NI embedded controllers with GPIB ports.
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.
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?
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)
> 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.
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.
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.
> ...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.
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.
Unfortunately it looks like this idea died. Any chance of getting this for a future release of LabVIEW?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
What do you need our team of experts to assist you with?
We'll be in touch soon!