Leaderboard

Has anyone ever given any thought to the LAVA community creating one single patch for the LabVIEW development environment? In other words, LabVIEW ships from National Instruments and then after installing LabVIEW, a user would then install the Community Patch. What would/could the patch do? 1. Install any number of useful tools in one go: right click framework, quick drop short cuts 2. Add useful OpenG tools 3. Update the configuration file to set settings different from the defaults that LV offers 4. Change the default custom probes 5. Fix bugs that the community has prioritized There are fewer developers here at National Instruments than exist in the wider LV community, and so it is not surprising that there are many great tools developed by members of the community that significantly improve the LabVIEW user experience. Identifying all the tools that I'd like to pull down and install -- or that I would recommend another user pull down and install -- is hard. Some of them are available as packages, but many others are just one-off VIs posted to a forum, like an improved custom probe. I might read the post one day, think, "Great! Let me grab that." So I copy it into my current version of LV. But I don't remember to copy it into LV on my other computers, and when it comes time to upgrade, I may not remember to copy that VI into the upgrade. Ideally such things would be flowing back to National Instruments and we in LV R&D would be over time adding them to LabVIEW's own installer. But there are often licensing problems with us picking up VIs from forums, and even when there aren't, the other priorities required to get a release ready often trump pulling such tidbits in. That got me thinking... Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience." That makes it easy for a user to just install one thing and get a set of reviewed improvements all at once. I suspect a lot of tools that otherwise languish in the hands of a few expert users would suddenly have a much wider adoption, and a lot of forgotten niceties would enjoy a renewal. Plus it would give LV R&D one package to review each release, instead of relying on someone happening to have tripped over an interesting post in the forums, which might help get these tools into LabVIEW's own installer. I have no idea if this has been thought about before, no idea how workable this would be, but it doesn't necessarily have to be all that organized. A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch". Thoughts?

In principle it's a good idea. However...... 1. All "patches" that I want can only be supplied by NI and, after one year, I have to lump it (I still use 2009 through choice). 2. Isn't most of what you are proposing exactly what the JKI thingy is for? (and I still argue that NI should have their own) 3. One mans meat is another mans poison so what some might see as "valuable" another almost certainly will not (all the items you list in No.1 for me). 4. If I see "useful stuff" it goes on my "G:\" drive which has 3 directories (2009, 2010 and 2011). Each is an exact duplicate of arbitrary "useful stuff" downloaded from forums, bits and pieces I've written and other miscellaneous bits and bobs (2009 is the "source" and gets copied accross to the others now and again). Each installed version on the dev machine(s) has it's search path pointing to the appropriate verson on the G:\ drive (the 2009 dir is backed up in SVN). Very little gets installed in the palletes above and beyond the vanilla install except my own re-use code (there are only 2 of them) and others on an as needed basis for that project (which are uninstalled after completion). This is the way I avoid dependancy and "compiled for later version" hell. I should perhaps also add that most of my work is on machines that are intentionally not internet enabled so "whoops I forgot to download and install that package" is not a viable proposition (sometimes machines are in different buildings or even in different parts of the country). The 2009 directory copied to a usb stick solves all that.

You can dig it up through the Example finder, or here: ..\National Instruments\LabVIEW xxxx\examples\general\strings.llb\Extract Numbers.vi

After I finished crying, I added an autotest to LV's nightly test suite just to make sure if anyone did try to change the private fields of those two classes in a way that they no longer coincidentally lined up, we'd see the crash on our end long before release. So far, so good. No one has felt the need to refactor strings. I still don't recommend it, which is why I was waiting to see if the "copy a constant with the right font" workaround would suffice before mentioning this dark alchemy. :-)