Michael Aivaliotis

I really like that icon. I vote we use that as the palette category icon.

Change your settings as shown in image.

The LAVA CR Web front-end (what we already have now) accepts Zip files or Packages. This will not change. We don't have a VIPM compatible LAVA CR repository yet and I don't know if we will ever have one. But I would love to have one and if the LAVA community yells loud enough (hint hint) maybe we will. Who knows But in this hypothetical future, if we did have a VIPM compatible LAVA CR repository, then only packaged submissions would go into that repository since that is the only format compatible with the VIPM repository. However we would continue accepting Zip files and packages into the LAVA CR Web front-end.

Ah, you're right. VIPM 2010 has a new built-in file counter feature which kicks-in when overwriting duplicate files. This means that when you uninstall a file, it is not removed completely until the file counter goes down to zero. However there is nothing we are doing right now to force an uninstall of a package unless, as you correctly stated, you declare a conflict. Of course you need to know what package to create a conflict for. One thing to consider is how to restore the original NI VIs. Are you performing a pre-install action to back them up and a post-uninstall action to restore them? Currently LAVA CR accepts submissions as Zip files or Packages. Only packages would be submitted to the LAVA (VIPM compatible) Repository.

In this specific case, LVOOP Accessor Hooks, I would suggest using a renaming convention (prefix or suffix) for your VIs. Also, NI has come up with conventions for Add-On developers located here: http://decibel.ni.co...d-on-dev-center Specifically, here is a doc that explains the recommended folder names for installing your stuff: http://decibel.ni.co...t/docs/DOC-8737 You really need to pay attention to where and how you install your stuff. VIPM 2010 already has all the NI conventions built-in. I assume you mean it's more important to have a LAVA Repository than it is to have a LAVA label in the product or filename. Right? I agree.

Even though package filenames\unique identifiers are important. They are not that critical with the latest release of VIPM 2010. We don't display these anywhere in the user interface of the VIPM install process or even in the package list. We are now using Product Names. So if you are building a package with VIPM 2010 (jgcode, why aren't you?), you can now specify a user friendly Product Name which is independent of the package filename\unique identifier. Yes, package filename\unique identifier are important, since this is what VIPM uses to determine package upgrades. As far as naming convention. I'm selfishly concerned here about LAVA submissions. I would like to see all LAVA Code Repository packages have LAVA in the product name or the filename (or both). In addition to being installed beneath a LAVA category in the palettes or menus (if it's a tool). As far as categories and tags. Yes! we agree that this is a great feature to have in VIPM. But we don't have it yet.

Something related: <iframe class="youtube-player" type="text/html" width="640" height="385" src="http://www.youtube.com/embed/1QHzI5HmXl4" frameborder="0"></iframe>

As a best programming practice, If you will be doing this often. I suggest you use the conditional disable structure so your VIs will not be broken. In the Mac frame place code that generates some dummy data or is a placeholder.

Most PDF apps show up as printers in Windows. I assume you want to print from LabVIEW. Just perform a printing action as you normally would through LabVIEW and select the PDF writer as your printer.

Just created a new forum here on LAVA for Certification and Training. If you see any topics that should be moved to this new forum then please flag them and they will be moved.

Ya, you just vanished. Wasn't sure what happened there. Did you get a ride in Norm's chick-mobile? We had to walk all the way back.