Allow easy access to top-level VI front panel controls and indicators in sub VIs

[vitoi]

What I find annoying, cumbersome and time consuming is when I want to take some code and "demote" it to a sub VI. If there are any top-lelvel (that is, user interface) front panel controls and indicators it becomes a nightmare. I know that references to the front panel controls and indicators can be used, but it's so much more work. So often, something which has grown that should be made into a sub VI remains at the top level.

Maybe I'm missing something here and there is some technical or useabiity issue.

Fundamentally what it is, is doing what passing a top level VI control/indicator reference to a sub VI and using the reference for control does, but behind the scenes.

[altenbach]

(First you are complaining for the first 85% of your post and then you conclude without and obvious product idea.)

Can you explain what you are actually proposing as an improvement for the current behavior?

What should change? Why is the idea better than what we have now?

[jcarmody]

In case your idea doesn't get implemented, here's my interpretation of what you asked for.

[X.]

jcarmody, are you not forgetting to close all these controls references? How handy it would be to have that done automatically, wouldn't it?

Actually this is a good example where it would be dangerous to do so, I admit. But still, one would want to close all those references after modifying the single boolean of this example...

[vitoi]

Exactly. If I have the top-level user interface front panel control or indicator and I want to use it in the top level VI, I can either wire to it or create a local variable. All very easy.

If I need to access the top-level user interface front panel control or indicator within a sub VI, I have to do something like jcarmody suggests. Simple Particularly for beginners this is a huge hurdle and there is a reluctance to create sub VIs, thereby leading to poor code.

Another workaround is to great a global variable that has the references to all the top-level user interface front panel control or indicator and use these references along with property nodes as needed. This is also time consuming and everytime I add top-level user interface front panel control or indicator I have to update the global variable. All too difficult for something all LabVIEW programmers must do all the time (or I'm doing something very wrong).

I see that I'm asked not only for a problem identification, but a proposed solution. I guess I'm after a "global local variable"; global in the sense it is accessible anywhere and local in that it directly links with the top-level user interface front panel control or indicator. Or perhaps any local variable of a top level front panel control or indicator could be flagged as such (some indicator on the local variable) and would be accessible from anywhere. It would need to be flagged as special to avoid the problem where the sub VI may have the same variable name. This solution would be as simple as creating a local variable. The solution would have to work such that when some code is selected and made into a sub VI that the "global local variable" would automatically be generated.

When I first started LabVIEW programming I assumed that a problem as fundamental as this could not possibly exist in LabVIEW and that it was something wrong in my approach. Five years later I'm still thinking this. Do others have this problem? 

[vitoi]

Exactly. If I have the top-level user interface front panel control or indicator and I want to use it in the top level VI, I can either wire to it or create a local variable. All very easy.

If I need to access the top-level user interface front panel control or indicator within a sub VI, I have to do something like jcarmody suggests. Simple Particularly for beginners this is a huge hurdle and there is a reluctance to create sub VIs, thereby leading to poor code.

Another workaround is to great a global variable that has the references to all the top-level user interface front panel control or indicator and use these references along with property nodes as needed. This is also time consuming and everytime I add top-level user interface front panel control or indicator I have to update the global variable. All too difficult for something all LabVIEW programmers must do all the time (or I'm doing something very wrong).

I see that I'm asked not only for a problem identification, but a proposed solution. I guess I'm after a "global local variable"; global in the sense it is accessible anywhere and local in that it directly links with the top-level user interface front panel control or indicator. Or perhaps any local variable of a top level front panel control or indicator could be flagged as such (some indicator on the local variable) and would be accessible from anywhere. It would need to be flagged as special to avoid the problem where the sub VI may have the same variable name. This solution would be as simple as creating a local variable. The solution would have to work such that when some code is selected and made into a sub VI that the "global local variable" would automatically be generated.

When I first started LabVIEW programming I assumed that a problem as fundamental as this could not possibly exist in LabVIEW and that it was something wrong in my approach. Five years later I'm still thinking this. Do others have this problem? 

[Peter_B]

Here is a solution I recommend using a shared variable bound to the top level vi's front panel indicator.

Single Process Shared Variable (SV)

The only downside with that solution is that you must enable the SV to be Network Published (NP) rather than just Single Process (SP).  That introduces unecessary overhead and it would be great if NI permittted it to work with the SV in SP mode.

[ErnieH]

Well. I posted an Idea for collapsible code that would work for this. Basically it would look like a sub VI, act like a subvi, editable like a sub vi, have an option to save as a subvi, but would be encapsulated into the top VI file.

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Collapsible-code/idi-p/1209625

[SteenSchmidt]

I think it's a bit disquieting when you need to embed small pieces of code, that interacts directly with the UI, in a subVI. I recognise the need for it, but it's not different from the requirement of having the UI control event structure on the Top-Level as well. And I think it promotes good encapsulated code, wherein you can easily determine in which execution system each piece runs. This is where intra- and inter-process communication comes into play - and passing control references isn't a good method due to a number of issues (performance, mainly execution system/thread switching etc.).

I use my own AutoQueue toolset for this type of data exchange (as well as for a lot of other things):

AutoQueue - Obtain.vi is actually a polymorphic VI with upwards of 30 types currently defined, where the above one is just one of the implementations. I just add types as I need them. AutoQueues are great for exchanging data between asynchronous pieces of code, for instance a Top-Level VI and its subVIs (see the 'Common use cases' section in the Context Help window above). It basically works like obtaining an ordinary queue, but you don't have to worry about the queue name, or about passing the queue reference around - you just drop in AutoQueue - Obtain.vi where you need to read or write data from or to, and the queues will auto-generate. And since I use named queues, the queue buffer will live as long as at least one end-point is currently running (you don't have to worry about the queue getting invalid due to the obtainer-VI going Idle).

I also have a DynamicDispatch and a ModuleControl toolset that builds on the AQ concept, but are designed for interfacing with dynamically dispatched VIs ('modules'). Herein is callback registration, 50+ defined commands, choice of ack or no ack, input data delivery to the dynamic VI without using the FP, and many other things.

Cheers,

Steen

[X.]

Steen, that sounds like code worth taking a look at! Is that possible?

[vitoi]

Hi Steen, I like your AutoQueue toolset. Is it available for others to use?

I didn't use queues in my first LabVIEW application since I needed to stop learning and start doing, however they have been indispensable from then on. (I also need to organise how I use queues as they tend to evolve as time goes and and can get quiet messy.)

It's a pity that LabVIEW has performance issues with using references. Perhaps another LabVIEW Exchange Idea is to get references to work efficiently.

However, for something as simple as accessing the top-level user-interface front-panel, it would be nice if something as simple as "create top-level local variable" was available. This would be essential for beginners and allow quicker programming for experienced users. I'm sure every LabVIEW programmer has encountered this problem in just about every project. Another advantage of the "top-level local variable" is that when Create SubVI is selected a SubVI that works the way it used to work happens - automatically.

If this idea is going to get noticed, it needs more kudos

[AristosQueue (NI)]

>It's a pity that LabVIEW has performance issues with using references.

> Perhaps another LabVIEW Exchange Idea is to get references to work efficiently.

They're already very efficient, particularly the queues and DVRs, but they cannot ever be as efficient as dataflow. That's provably logically impssible. As for the control references, they have to take the UI thread swap penalty. There's no way around that without loss of data integrity or an even slower mutex lock.