UI Interest Group Blog

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 

Cool Tools for controlling the Front Panel (UI) Objects

Member

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:

UIRef1.png

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

UIRef2.png

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:

UIRef3.png

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:

UIRef4.png

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):

UIRef5.png

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

Enjoy!

Br,

Samuli

EDIT v4: Added updated files. Also for LV 8.6

Style is Everything
Comments
Active Participant

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.

Combined.png

Member

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.

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Active Participant

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.
Member

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":

UIRef6.png

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

Style is Everything
Member

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

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Active Participant

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.

Active Participant

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.

Member

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

Style is Everything
Member

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

Member

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

Style is Everything
Member

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

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Knight of NI Knight of NI
Knight of NI

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


___________________
Try to take over the world!
Member

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.

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Member

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.

Style is Everything
Member

Hi Matthew,

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

img.png

Br,

Samuli

Style is Everything
Member

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.

TraverseTools.png

"All truths are easy to understand once they are discovered; the point is to discover them." -- Galileo Galilei

Member

Big Thanks settlesj! live and learn

Style is Everything
Member

Hello!

Great work!

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

Andrei

Member

Hi Andrei!

I added the files for LV 8.6 Enjoy!

Br,

Samuli

Style is Everything
Member

Thank You!!!

Member

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

Member

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.

Active Participant

Its really good..

Regards,
Silver_Shaper
CLD