Jump to content

Get Control Reference by Name


Recommended Posts

I have a VI that I use a ton in my code. The problem is, it is kinda slow. I am looking for a way to speed it up.

The point of this code is to get a reference to a front panel control by name. The VI has an input for the VI Ref that has this control on the front panel and the name of the control to find (string).

The output is the control's reference.

I use this to monitor front panel objects from deep in my calling tree. One good example is to monitor an Abort button on the GUI's front panel and be able to stop a loop in some deeply buried sub-vi. The sub-vi just check the status of a button called 'Abort' on it's top static caller.

If you have any thoughts on how to accomplish this code in a way that uses less CPU cycles, please post it here.

thanks for the help.

-John

Link to comment

I have almost the same VI in my lib, I guess with very huge arrays of control refs (not very likely, I assume) this could be a bit faster since there's no fork on the array. The search loop is not any different..

But do you use this VI inside loops? I guess you could just get the ref. once outside of a loop, it won't change during program execution..

http://forums.lavag.org/index.php?act=attach&type=post&id=5387

Link to comment

The way I get around this issue is to create a typedef cluster containing control references to any control I wish to programmatically manipulate within my application. I bundle by name all my control references during code initialization, then unbundle the references whenever I need them in other places in my VI. If I need any of these references in a subVI, the typedef cluster is on the conpane of the subVI so I can unbundle the reference(s) I need within the subVI. Since it's a typedef, I can add control references to it as I develop code. This avoids any array searching for references and makes the code very fast.

This is the approach I take in all my UI VIs (i.e., any app where I will be programmatically modifying UI elements).

-D

Link to comment

QUOTE(Darren @ Apr 2 2007, 09:12 PM)

The way I get around this issue is to create a typedef cluster containing control references to any control I wish to programmatically manipulate within my application. I bundle by name all my control references during code initialization, then unbundle the references whenever I need them in other places in my VI. If I need any of these references in a subVI, the typedef cluster is on the conpane of the subVI so I can unbundle the reference(s) I need within the subVI. Since it's a typedef, I can add control references to it as I develop code. This avoids any array searching for references and makes the code very fast.

This is the approach I take in all my UI VIs (i.e., any app where I will be programmatically modifying UI elements).

-D

Can you post some example code to illustrate this? That would be a really great help for those trying to follow what you're describing.

Link to comment

When I have had to do this type of thing I have used an array of Control Refs and an array of Control names bundled in a cluster for the VI. For each VI that I want to do this to I create a cluster of the arrays on the first call to get a control ref. On later calls, I obviously do not get the refs again, I just search the arrays. The clusters themselves can be kept in an array.

Usually, if I know I have to do this I don't even wait for the first call, I just do it at program startup and initialization. If I know I won't need all the refs I usually then filter the arrays.

Cheers

Link to comment

Here are a couple of screenshots to illustrate the method I described. These are actually snippets of code from the VI Analyzer UI. Here is the code during initialization of the main UI that bundles control references into the typedef cluster...these are references of any controls and indicators that I need to programmatically manipulate throughout the execution of my UI code:

http://forums.lavag.org/index.php?act=attach&type=post&id=5392

This cluster is wired to the border of my main event structure for my UI. In any case of the event structure where I am programmatically manipulating UI elements, I simply unbundle whatever references I need from that cluster. If I have a subVI that needs the references, I pass the cluster into the subVI via its conpane, and then unbundle whatever references I need within the diagram of the subVI, as seen here:

http://forums.lavag.org/index.php?act=attach&type=post&id=5393

I hope these screenshots help illustrate my method. It's very easy to deal with front panel controls with VI Server when you have access to any of the control references you need at any point on the diagram. If there's another control I need access to, I simply add it to the Bundle By Name (and the typedef). To make things easier for me, I also keep the control references organized alphabetically in the typedef cluster by changing the Cluster Order whenever I add elements to the cluster. This gives me an alphabetized list whenever I operate-click on an Unbundle By Name to select the proper reference to unbundle.

Let me know if you need any more clarification on this method.

-D

Link to comment

I submitted a few VI's to the CR that I use to Get a Reference to all My Controls and a vi that allows me to search thru them to obtain the reference that I want. Hopefully they will be made available soon once I get them approved. I hope that you will all find those vi's useful when dealing with control references. Basically what I use the vi's for are to obtain all the references on a calling vi, I then pass them in a shift register in my application, and finally use another vi to obtain the reference I want by name.

If you get a chance to stop by and check the CR and take a look (after they are approved of course) I would appreciate any feedback and recomendations to improve on them.

Dave Graybeal

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.