Cool Tools for controlling the Front Panel (UI) Objects

[~Samuli]

Hi All,

I created this tool for manipulating Front Panel objects (Controls/Indicators). If you work with UIs a lot then this tool is great for you! The main idea is that usually when you need to control UI object properties you will first put those references to for example cluster (because you cant use Array) and then reuse that cluster/references later on with your code. But that is not really good way to do it. Mainly because it is a mess and it always requires some work. Lots of references with different reference types etc. Lots of wires going all over etc.

So developers usually start with collecting those references like here:

But I don't like that method. Why not just do it like this:

That VI will automatically get all references to really fast memory place which you can use later on where ever you want (subVIs etc) with this another tool:

So you can use Label names to get the right reference to that control or indicator Is that cool or what? And it's pretty fast too. So which Control&Indicator types are supported? Well here is the list:

You may also use that function with any VI that is in LV memory by calling it with VI name when you initialize that function (if you leave it empty it will use caller VI):

I also included an example program that you can use...

Enjoy!

Br,

Samuli

EDIT v4: Added updated files. Also for LV 8.6

[SercoSteveB]

Nice, will be useful.  Think I would have gone for a type defined enumerated type (instead of a string) to reference the control/indicator by name.

[B.Settles]

I developed the same thing for my own use once the traverse VIs were exposed, but I never added the polymorphic part for the control type...Nice touch.

[Matthew_Kelton]

If you use an enumerated data type, you have some issues.

1. You have to have multiple copies of your subVIs (this tool is generic and can be used over and over again) for each VI you want to control since the enum list will change for every VI.
2. You could make the input variant so the subVI could be reusable, then you can get the enumerated item from the variant (OpenG or a low level LabVIEW VI will do this).  You still need an enumerated data type for every subVI, and this would slow down the above code.
3. If you are willing to live with #2, you can use a combo box typedef instead (you would still need to have one for every VI).  This will allow the code as-is to be used since it is just a special string.

[~Samuli]

I like to use String instead because then it's more reusable with other projects (more general tool). But yeah you are right that typedef enum would be usefull too. Instead using typedef enum directly I would use "typedef enum + Format into String function":

This way I could separate the main function from the current project... it's just my old habit... I try to keep "general tools" separated from the current project

[B.Settles]

Any chance of saving back to an earlier version...haven't gone to 2011 yet.

[Matthew_Kelton]

I think the only issue I see with this at first glance is that you can only access one VI at a time and have to access the full VI.  I understand the issues with supporting multiple VIs (controls with duplicate names, for example).  I have a current project that this would have worked well for in the past if I were able to break up the control refs into groups to use in subVIs.  Now it is being switched to subpanels, so the need for the references will go away.

[Matthew_Kelton]

If that is the bahavior you want, OpenG has the Get Strings from Enum function.  One output is the value of the enum.  The input is a variant, so in your case, you wouldn't have to constantly drop the Format into String.  You use the OpenG function inside your VI and change your string to a variant (or use both if you still want to support a string input).  Wire your enum into the variant.

[~Samuli]

I added the LV 2010 Version Let me know if it works?

[Drew.Rankin]

Steve,

At first thought, I agree with you; however, after looking at the possibility of using the type def'd enum, I think that using one would complicate things. Samuli's approach is sound and simple with the caveat that if you change the names of the controls, you have to hunt down every created constant manually. Additionally, I don't like the polynomial vi that cannot be automated using default inputs, but that's more of a personal nit.

I think given enough thought, the community can improve Samuli's design. I agree that having references hidden in a functional global without explicitly creating them on the block diagram is a huge help. Creating control references has always been one of the things I have struggled with how to do in a well thought out manner.

Drew

[~Samuli]

MatthewKelton wrote:

                       

I think the only issue I see with this at first glance is that you can only access one VI at a time and have to access the full VI.  I understand the issues with supporting multiple VIs (controls with duplicate names, for example).  I have a current project that this would have worked well for in the past if I were able to break up the control refs into groups to use in subVIs.  Now it is being switched to subpanels, so the need for the references will go away.

                   

Well it's quite easy to add this function a functionality to support multiple VIs. I will do that soon

[B.Settles]

Thanks for posting an older version...I see there's a new control type in 2011.

[tst]

While I understand the convenience this gives, I really don't like the way it disconnects the controls from the code (no type safety, names could change, etc.). Usually I only automate something like this if there's a large number of controls which have a shared logic of some kind and then usually each control will embedded info for how to manage it.

Under normal circumstances, I would try having the code in the same VI as the UI, but if I need to move it, I would generally prefer going with the cluster of references method, and at least I have a shortcut which let's me create that code in about two seconds - https://decibel.ni.com/content/docs/DOC-5813

[B.Settles]

My main reason for doing something similar to this was that my code did control manipulation in a couple different places (i know not the best approach) and I didn't feel like passing a wire through several levels of VI's just to get it to some low-level VI. I know that's anti-LabVIEW, but sometimes I wish there was a way of using a pointer in LabVIEW.

[~Samuli]

tst wrote:

                       

While I understand the convenience this gives, I really don't like the way it disconnects the controls from the code (no type safety, names could change, etc.). Usually I only automate something like this if there's a large number of controls which have a shared logic of some kind and then usually each control will embedded info for how to manage it.

Under normal circumstances, I would try having the code in the same VI as the UI, but if I need to move it, I would generally prefer going with the cluster of references method, and at least I have a shortcut which let's me create that code in about two seconds - https://decibel.ni.com/content/docs/DOC-5813

                   

Well some people like Apples and some Nokias (not so many people like Nokias anymore) I actually like to hide the references from the code. I have a single function for Queues, File operations, Dynamic Events etc where I hide the references from the code. It will produce cleaner block diagram because there is no need for multiple shift registers and all that wiring inside SubVIs etc etc and it's more flexible. Sometimes when the performance is the key issue then I use "visible" reference lines so I don't loose that small overhead. 98% of the time I don't have to use those and that gives me more development speed and cleaner Block Diagram. But every designer has their own habits.

[~Samuli]

Hi Matthew,

I just updated the files. Now you can add Front Panel objects from multiple VIs by using the ADD operation

Br,

Samuli

[B.Settles]

Hey Samuli,

You're probably aware of the Traverse tools that Darren Nattinger (pretty sure it was him) finally exposed in 2010 (or 2009), but they do some of the work that you are doing as far as finding control and indicator references, especially in Tabs and Arrays. If you aren't, take a look so that you don't have to repeat something that's already part of the LabVIEW package. I used this when I built my tool, but like I said earlier you added the nice touch of the polymorphic VI for the different types.

[~Samuli]

Big Thanks settlesj! live and learn

[Andreik_ee]

Hello!

Great work!

But can You put Your tool compiled for LV 8.6? Please!

Andrei

[~Samuli]

Hi Andrei!

I added the files for LV 8.6 Enjoy!

Br,

Samuli

[Andreik_ee]

Thank You!!!

[atwoodtj]

For the 2010 version, I had to delete the case for 'DataValRefNum' in the 'UI - All UI Objects Refs Memory.vi'

[Sambo]

Samuli,

Interesting tool! Thanks for sharing.

I could be wrong, but it looks like your "CLOSE ALL" sate is unnecessary! In ("INIT", "ADD") state of 'UI - All UI Objects Refs Memory.vi', the inner loop is always exited with an empty array of Control Refnum. I don't claim expertise on the subject of closing Refs and I wish someone gives us a link that clarifies this subject. I always wonder when Refs should be closed. For instance, when we create a Ref constant to a control from the right click menu of the terminal do we have to close it at end of Prog? In  'UI - All UI Objects Refs Memory.vi', the Control Refs are accessed directly from the Caller Vi's Panel; do we have to close these Refs when done?

Finally, I do see that you're opening a VI Ref; shouldn't this Ref be closed in "CLOSE ALL"?

Sam B.

[Silver_Shaper]

Its really good..

[F.B.]

I just found this nice tool. Is it possible to manage DAQmx Name Controls (DAQmx Physical Channel), DAQ Channel, etc.?

Or did I just overlook this option?

Frank