LabVIEW
Generating an array of main menu front panel control refs for passing to subroutines
id wrote:
Found it there also. Thanks Darrin. This is awesome and I agree with tbob - why isnt this thing on the tools menus. It is somehting I would use in almost all my apps.
tbob's request is slightly different than yours.
Adding it to the palette is a good idea.
Re: Nugget about using VI's in VI.lib...
Any or all VIs that are not on the palette are technically "off-limits".
Example:
THis code (LV 7.1 version attached), written in LV 7.1 uses the VI that writes the file to make sure the file is saved rather than waiting until shut-down to update the file.
That code will not even open in LV 2009 because that VI was not on the palette so it was removed.
So keep in mind that anytime you use a vi from vi/lib that is not on the palette, you can be locking your LV version OR delaying moving to the next version.
YOU have been warned (I wish I had been)!
Ben
By name and remeber if you re-name it the code looking for that control will break so show the caption and hide the name.
After fighting with that for a while you may want to look at my bundling solution again. 
Ben
I agree with Ben, use the name to reference the controls if possible. For me it is usually simple and effective since I am the only one touching the names and if I screw something up I get what I deserve. With scripting, you can reference by type as well without too much difficulty.
About the vi.lib issue. I was bitten in the butt by the config files, but it was more of a nuisance and by that time it was a well-known issue (just not to me). NI's response was that we should probably be thanking them for doing it, as a user I saw it a bit differently. I think we all agree that better (ahem, any) documentation would be in order. For a while I was chastened and started pulling back on my usage and advocation of vi.lib VIs. Then I had an epiphany where I learned to Stop Worrying and Love the VI.lib. I figured that NI could pull the stunt with the config files since it affected a small portion of the users, but if everybody started using it then NI would have to take notice. So now I tend to unashemedly push the VIs, but with the caveat that you know the risks. You never want to be the one to recommend a bad restaurant and you don't want to be the one that pushes a VI that gets yanked arbitrarily by NI with no warning.
That said, if I weren't so busy (translation lazy), I would start a thread where we could post our favorite VIs from there. You will find the documentation to be lacking at best and non-existant in many cases so we can try to fill the void with case studies. Password protection is also a nuisance many times. As a teaser, here are some of my recently used vi.lib VIs (and yes I have been playing with pictures a lot recently). I think with enough buzz we can get NI to promote some of the vi.lib VIs to either the pallete or non-password protected status so we can use them without fear.
Here and here are two things which can save you a huge amount of time. Not dissimilar to the XControl Ben was describing, they will allow you to select a bunch of controls and instantly create an array or of cluster of references for them.
As for the vi.lib issue, you should consider that a popular hack does not necessarily mean it won't get changed. I'm assuming a lot more people modified the report gen toolkit, but NI still converted it to a library (although I get the feeling they weren't aware of people modifying it at the time).
