Search the Community

In case anyone is interested, I wrote a short blog post on the Add-on Dev Center (ADC) blog about Team LAVA and the LAVA Code on LabVIEW Tools Network project. For those who don't know the ADC is a NI community group hosted by the LabVIEW Partner Program team that contains (hopefully) helpful documents on creating a third party add-on for the LabVIEW Tools Network. This is also where all of the Compatible With LabVIEW information and requirements are posted and kept updated as we make changes. We occasionally post blog updates with interesting information or tips that would interest those creating LabVIEW add-ons. Feel free to join the ADC community, follow the blog updates and provide us with any feedback you have on anything you see. Link to the blog post: LAVA Code on LabVIEW Tools Network https://decibel.ni.com/content/groups/labview-add-on-dev-center/blog/2012/02/03/lava-code-on-labview-tools-network

Hey all, As you may know in order to have a toolkit placed on the LabVIEW Tools Network it has to pass Compatible With LabVIEW certification. One of the requirements for the Compatible With LabVIEW program is that tools may not be located on the top palette, but should exist within one of the existing top-level categories such as Programming, Measurement I/O, Data Communication, etc. The reason behind this requirement is that the LabVIEW Palette can get quite bloated when you have many toolkits/modules installed. With just the full Developer Suite installed, there are over 20 top level palettes. Adding third party tools to this list will very easily bring the functions palette to grow off of the screen for a standard 1024x768 monitor. The secondary reason behind this is that this layout will help users find the functions more easy that will help them. For example if the user is looking for some data communication protocol, they are more likely to look in the "Data Communication" palette then in a sub-palette called "My Data Protocol" under a top level "DavidSoft Inc". I wanted to point this out so as you all start creating their toolkit for submission to Team LAVA or the LabVIEW Tools Network, you can take this into consideration ahead of time. However, with many things in our program, nothing is black and white. If there are special cases in which a toolkit especially should be on the top level, we will consider letting it go as such. One of these cases is OpenG. Since OpenG has a long-standing reputation and is known to be found on the Top level, it would be more hurtful than beneficial to require it moved to the Programming palette. If anyone has suggestions or ideas of other corner cases that would benefit from this top level location, or have comments or opinions for or against this policy, please feel free to bring them up here for debate/discussion. --David Out