David_L

Well here is my bootleg workaround, but it works. Read an Image, load that image into a 2D picture control without a frame, export 2D image control to clipboard. Then in the VI in question delete the image you want to replace and paste the new image to the same location... Not ideal by any means, but it does the trick I believe. I also made the assumption that there was only one image on the block diagram already, and you want to replace it with a PNG. But that's easy enough to fix I'm sure. Change Block Diagram Picture.vi

I couldn't find a way to add or replace an image using scripting (however that does not mean it doesn't exist). One thing you could try is deleting the original image and then using the "TopLvlDiag:Paste" Method to paste an image from the clipboard to the block diagram. However you'd have to first get the image on to clipboard programmatically, which I haven't quite sorted out yet.

For the record, Bob has finally released the VI to XML Documentation Tool. This will analyze a set of VIs and create HTML and XML files corresponding to the VI descriptions and controls and indicators etc. You can plug these into FAR or another CHM creator to make awesome looking documentation.

One of NI's tech writers gave a presentation on documentation at NI Week and he (as well as others) use FAR to compile HTMLs into CHMs. I haven't used it personally, but I understand it's fully functional shareware and have seen good results from it. Also keep an eye on this document as we will soon be releasing a free little tool that analyzes a collection of VIs and creates HTML files similar to the detailed help for LabVIEW VIs. We have had a few of our partners use this along with FAR to create very nice looking Help docs...

Idea-ified

Greg - Your description exactly reflects the reason we want developers placing palettes under the existing top-level palette. As you mentioned, you can't place them inside lower level palettes, but at least the top level is a start. Perhaps we could get some momentum on the idea exchange for allowing palettes to be placed under the lower level palettes (i.e. arrays, timing, etc). I'll post an idea for this and update this thread when I do so.

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

Thanks for the shout-out and welcome Jon. As the man said, if you have any questions about the LabVIEW Tools Network, Compatible With LabVIEW program, LabVIEW Add-on Dev Center or anything else about creating your own LabVIEW Add-on, please feel free to shoot me a message and I'm more than happy to help. Peace, love and LAVA, David

There were MANY performance improvements in LabVIEW 2011. My favorite is that I don't need to wait for Quick Drop any more. It looks like this idea and this idea are no longer needed. :-) David