Palette Structure and Appearance

[RDR]

What to consider

• Where is your palette located?
• Have you followed the documented naming conventions for palette categories and palette names?
• Is your palette organized logically?
• Did you avoid using text-based function names for palette items and use whole English words to describe the item (no abbreviations) names?
• Did you take care to avoid duplicate palette entries in User Libraries and User Controls when using user.lib?
• Have you removed ".vi" from palette entries by removing it from the 'Window Name' property in VI Properties?

Palette Location

There are several places to store your palettes for both Controls and Functions, some of the more common locations are:

Functions

• User Libraries (\user.lib) - This palette should be used for personal VIs, but not for 3rd party add-ons
• Instrument I/O (\instr.lib) - This palette should be used for Instrument Drivers and communication protocols for connecting to hardware (VISA, GPIB, etc)
• One of the existing functions palette categories (Programming, Mathematics, Addons, etc) - Most 3rd party add-ons should be installed to one of the existing categories.
  • Programming - VIs and Functions that are the basic building blocks for a VI.
  • Measurement I/O - VIs and functions that interface with NI-DAQmx and other data acquisition devices.
  • Instrument I/O - VIs and functions that interface with GPIB, serial, modular, PXI, and other types of instruments
  • Vision and Motion - VIs and functions to interface with any of the NI Vision and Motion products.
  • Mathematics - VIs that perform many different kinds of mathematical analysis
  • Signal Processing - VIs that perform signal generation, digital filtering, data windowing, and spectrum analysis
  • Data Communication - VIs and functions that exchange data between applications
  • Connectivity - VIs and functions that work with .NET objects, ActiveX-enabled applications, input devices, register addresses, source control, and Windows registry keys.
  • Control Design & Simulation - VIs and functions that perform model-based control design, analysis, and simulation and other related tasks.
  • Express - Express VIs and functions that build common measurement tasks.
  • Addons - modules or toolkits that do not have a natural fit in the other existing palettes
• Your own functions palette category - While this is possible in LabVIEW, it should be avoided for 3rd party add-ons to avoid cluttered palettes and provide a better user experience.

Controls

• User Controls (\user.lib) - This palette should be used for personal controls and indicators, but not those installed with for 3rd party add-ons
• One of the existing controls palette categories - Most controls and indicators installed with 3rd party add-ons should be installed to one of the existing categories.
• Your own controls palette category - While this is possible in LabVIEW, it should be avoided for controls and indicators installed with 3rd party add-ons to avoid cluttered palettes and provide a better user experience.

The locations listed above are acceptable as long as a core set of rules are followed:

1. Do not modify any of the shipping .mnu files
2. Use the naming conventions outlined in the File and Folder Names for Integrating into LabVIEW document whenever possible

Palette Organization

Regardless of where you choose to host your palettes, it is important to organize your palettes logically.  A set of general rules for palette organization are as follows:

1. Commonly used items should appear higher and to the left side of a palette, and less commonly used items should appear lower and to the right in a palette.
2. Items used together should be placed together and on the same row when possible. If you have items that are used in a specific order, try to place these in the same left-to-right order as your customers will use them.
3. Use subpalettes to group like items, but try to keep the commonly used items on higher levels in your hierarchy

Item Names

When naming your palette items there is also a general set of rules to follow:

1. Avoid using names based upon function names from text-based languages, which can be difficult to read and search for.
2. When possible, try to choose unique function names as this will help customers find your functions through Quick Drop
3. A common prefix among palette items is recommended to help differentiate your functions from others with similar names
4. Be consistent throughout your API!

Tools for Editing Palettes

The palette editor shipped with LabVIEW (Tools > Advanced > Edit Palette Set...) can be used to create and edit .mnu palette files; however, with VI Package Manager 2010, a tool from JKI Software, there is a more intuitive palette editor for add-on API developers.  In the VI Package Manager 2010 version, the Community or free version now supports building packages -- I strongly recommend trying it out as we're supporting VI Packages as a means of distributing products on the LabVIEW Tools Network!

[David S.]

If my add-on library ships with examples for its use, is it okay to put them in an "Examples" subpalette of my user.lib palette?

[chris.b]

As long as the examples are displayed in the Example Finder, this location is fine. Examples can be located in user.lib, instr.lib, or examples, and must have a bin3 built for them: https://decibel.ni.com/content/docs/DOC-9211

[Kosta]

My understanding is that the question was not about physical location of examples, but about their presence on palettes.

Functions palettes are meant for subVIs, functions, and structures you want to drop into block diagrams.  Controls palettes are meant for controls you want to drop into front panels.   Example VIs typically do not fall in either of these two categories.