Customizing the LabVIEW Development Environment

2002 Jim Kring

jim@jimkring.com
All Rights Reserved

LabVIEW Tools
After using LabVIEW for a good period of time, a developer or organization will
accumulate many tools to help them do their work. These tools will include LabVIEW
primitive-like VIs; toolkit-like packages of VIs; instrument drivers; VI, control, and
software component templates; application architectures; and edit-time development
tools. Fortunately LabVIEW provides several mechanisms to tailor the LabVIEW
development environment to suit the working needs of the developer. In this article I will
examine those mechanisms and explore ways that the developer can use them to
customize their work environment. In the conclusion, I will describe a way to propagate
those changes onto LabVIEW installations on other machines.
Again, the types of tools that a developer or organization will create can typically be
divided into the following categories:
LabVIEW Primitive-like Functions - These are small reusable VIs that look and feel
like the functions in the default palette, which come stock with LabVIEW. Developers
who use LabVIEW daily will often find gaps in the functions found in LabVIEWs
palettes and need to augment them.
LabVIEW Primitive-like Custom Controls - These are custom control, which are
similar to those in the default controls palette. They may be buttons with fancy graphics,
or things like the clever codeless radio button that appeared in LTR a long while ago.
LabVIEW Toolkit-like Packages - These are groups of VIs that collectively achieve
some task. An example would be GOOP classes or any of the GOOP-like
synchronization tools such as the queue, semaphore, notifier, and rendezvous as well as
LabVIEW add-ons like the PID, Fuzzy Logic, or Internet toolkits.
VI and Control Templates - In an effort to save time, when design patterns are common
to an organization or repeatedly used by individuals, VI and control templates may be
used as a starting ground for development.
Software Component Templates These are a collection of VIs that work together to
achieve some compartmentalized functionality, like a configuration dialog with
configuration data file storage and retrieval. It may have one or more VIs, custom
control type definitions, and data files that need to be copied to a new location and
possibly renamed while preserving the relative linking of the files
Application Architectures - These are project templates or recycled projects. To save
time one can reuse entire collections of several tools that have been implemented to solve
specific large-scale tasks. Examples might be a data logger, test executive, device
controller, etc.
Instrument Drivers Companies that work with a specific set of instruments and use
them in a specialized manor may develop a custom library of instrument drivers that suit
their classes of experiments. They may wish to share one collective set of drivers
company-wide.
Edit-time Development Tools - These are LabVIEW programs that are designed to run
while you are developing in LabVIEW. Some of the best examples of these are tools that
1

ship with LabVIEW, for example the VI Library Manager, Web Publishing Tool, and
Application Builder. These are all applications written in LabVIEW that are designed to
help you when you are building your own LabVIEW application. Most of the edit time
tools that an individual or organization might write would be designed to reduce the time
spent doing mundane repetitive tasks like renaming groups of VIs with a common prefix,
or changing VI properties of groups of VIs at a time. However, they may also be
designed to provide information and insight into the development environment itself. For
example, an application might list all VIs in memory or all top-level VIs. It might allow
you to select a VI in memory and open the VI by selecting it from the list or edit the VIs
properties, such as its VI Info Description or Execution options. With the advent of VI
server and hence LabVIEWs introspection capabilities, the possibilities are limitless for
new developer tools written purely in LabVIEW.

Customization Options
I have defined the types of tools that one may wish to integrate into the LabVIEW
development environment, so now an exploration, is necessary, of the options available
for bringing them into the work area. LabVIEW provides some out-of-the-box tools for
customizing the LabVIEW development environment, but also has some undocumented
and under-documented features that the developer can employ as well.

Custom Palettes
Chapter 3, Section 1 of the LabVIEW User Manual (<LV>\manuals\lvuser.pdf) is
entitled Customizing the Controls and Functions Palettes. It describes several
mechanisms for modifying the LabVIEW Controls and Functions palettes. The simplest
way, and the one that most people are familiar with, is to place their reusable VIs and
Controls in the <LV>\user.lib or the <LV>\instr.lib directories. When LabVIEW starts
up, it looks in these locations and builds subpalettes and icons reflecting the contents of
those locations. The <LV>\user.lib contents are reflected in the FunctionsUser
Libraries palette and the <LV>\instr.lib contents are reflected in the
FunctionsInstrument I/O palette. Another option that you have is to add a toolset,
(LLB or directory of VIs) to the <LV>/vi.lib/addons folder. These toolsets will appear
as subpalettes at the top-level of the Controls and Functions palettes. Lastly, you can
create an entire palette view. A palette view allows you exact control of VI and
Control icon locations and subpalette icons, names and locations within your custom
palette. This is by far the most powerful of the palette customization options, so I will
further describe its features.
LabVIEW stores all the palette views in the <LV>\menus folder. The menus folder
contains subfolders, each of which corresponds to a palette view. Inside the palette view
folders are one or more files. Lets take a good look the contents of a palette view folder.
root.mnu - This file defines the top-level Functions and Controls palette contents of the
palette view. However, LabVIEW will continue to add the contents of
<LV>\vi.lib\addons to every palette views root menu
readonly.txt - this file, if present, disables some of the palette editing features. It
effectively makes the palette view read-only. This file consists only of a carriage
return \r character.
*.mnu All the other .mnu files in the palette view folder define the palette views
subpalettes. It is worth noting that a .mnu files palette can embed any other .mnu files
2

palette, regardless of location. However, if you plan on distributing your custom palette
view, you should ensure that any .mnu files that you created or used as subpalettes are
located inside the palette views folder. It is bad practice to link to .mnu files that exist
inside of other palette views. This could happen if you tried to insert a submenu from an
existing .mnu file and you selected the file manually with the file dialog. You could
potentially insert, and therefore edit, a palette that belonged to another palette view. The
bottom line is: when you create new submenus, make sure that you save your .mnu files
in the palette view directory of the one you are editing and dont insert subpalettes from
existing .mnu files in other palette view directories.

.mnu file basics

.mnu files define the LabVIEW palettes, so the developer really needs to know what an
.mnu file is and what it does. It is useful to understand exactly how they work so that the
developer can use them effectively. Lets first take a look at the LabVIEW
documentation on palettes and how they are stored on disk.
LabVIEW User Manual Excerpt (3-5)
How LabVIEW Stores Views
The .mnu files and .llb files contain one Controls palette and one Functions palette each. In
addition, each file contains an icon for the Controls and Functions palettes. You must store
each subpalette you create in a separate .mnu file. When you select a view, LabVIEW
checks the menus directory for a directory that corresponds to that view. It builds the toplevel Controls and Functions palettes and subpalettes from the root.mnu file in that
directory that LabVIEW automatically creates every time you create a view. For each VI or
control, LabVIEW creates an icon on the palette. For each subdirectory, .mnu file, or .llb
file, LabVIEW creates a subpalette on the palette.
As mentioned in the LabVIEW User Manual Excerpt (3-5) .mnu files and .llb files
contain one Controls palette and one Functions palette each. But what exactly is a palette
(what information does it contain)?
Submenu Name This is the name that will be seen
from the palettes parent palette, which embeds the
palette as a submenu. You may edit this only from a
parent palette by right-clicking on the submenu icon
and selecting Rename Submenu, as shown to the
right.
Palette Icon A palette has an icon that is seen in a
parent (another palette that embeds the palette as a
submenu). Just like the Submenu Name you may
only edit this from a parent palette by right clicking on
the submenu Icon and selecting Edit Submenu Icon.
VIs/Controls A palette contains information on VIs/Controls
(by relative path if beneath the LabVIEW) and their locations
on the palette, as well as whether the VIs in the Functions
palette are to be Merged. Merge VI is an option that causes
the contents of a VI to be added to the target VI instead of
adding a subVI to the target. The contents of the selected VI
are merged into the target. (this setting is shown to the right)
3

Submenus A palette contains links to other palettes within LLBs or .mnu files and their
locations on the palette.
Synchronize with Directory - This option, if enabled causes the palette to build itself
dynamically on startup based on a specified directorys contents. This option may only
be set from a parent palette by right clicking on the submenu icon and selecting
Synchronize with Directory. When set to TRUE LabVIEW will ask you to define the
directory with which to synchronize.

Lesser-Known Palette and .mnu File Facts

The text that appears as a VIs name in a palette is the VIs default Window Title
(Font Panel Window:Title VI server attribute). If the VI or CTLs Window Title
is set to Same as VI Name the name will also display the .vi or .ctl extension string
when viewed from a palette. This may or may not be desirable to you. You will
probably want to rename the Window Title by removing the .vi or .ctl suffix.
A palette views name is the name of the palette view folder in the <LV>\menus
menus directory. However, this name can be overridden by placing a text file with
the same name as the palette views folder (but with a .txt extension, of course) in the
menus directory. The text in the first line of this file is used as the name for the
palette view. *Note: this name override method occurs frequently in the
customization features and it specifically relates to how the Tools and Help menu
item names are generated -- this feature will be described in the next section.
When you create a palette view, LabVIEW will create a new folder inside the menus
folder with the name that you chose for your palette view. The only file that it will
initially contain is root.mnu. This file links to .mnu files (subpalettes) in the default
palette view (<LV>\menus\default), however, if you edit any of the subpalettes in
your new palette view, LabVIEW will create copies of the default .mnu files that you
edited and place them in your palette view folder. If you delete your modifications to
a .mnu file that LabVIEW copied over from the default palette view folder, such that
it is identical to the original file, LabVIEW will delete the copied .mnu file in your
palette view folder. *Note: the file may not be identical even if the palettes look the
same. If you try to delete the .mnu file manually you may see a ? icon in the parent
palette because the parent palette is still linking to the file you deleted. You would
then have to relink the parent palette to the .mnu file in the default palette view folder.
This is done by first deleting it and then inserting a submenu link to the original .mnu
file located inside the default palette view folder. (This is the one exception to the no
palettes from other palette views rule mentioned earlier)
Sometimes when adding to a subpalette, whose .mnu file does not yet exist in your
palette view, LabVIEW will cause that palettes parent to show a ? icon for the
submenu you were editing. For example, I added some functions to the Additional
String Functions palette. After I saved my changes, the String pallet showed a ?
icon for the Additional Strings Functions submenu. This is easily remedied by
copying the icon from the default palette. Find the desired submenu icon in the
default palette view, right click on it, and chose Copy Icon. Now go back and edit
your palette view, edit the missing submenu icon, and paste the icon that you copied
from the default palette view.
The only way to remove a palette view is to delete its
folder inside the menus directory.
When you insert a submenu, you can choose to Link to a
directory (dialog shown to the right). This will create a
4

file called dir.mnu inside of the folder you select. This .mnu file will have the setting
Synchronize with Directory set to true and the target directory set to the .mnu files
parent directory. This effectively allows you to create a folder similar to
<LV>\user.lib and <LV>\instr.lib. It will automatically generate icons and
submenus based on the folders contents. Inside this folder, you can place LLBs, VIs
and other folders containing dir.mnu files.

LabVIEW Tools and Help Menus

LabVIEW provides a mechanism, which allows the user to open VIs and help files by
selecting them from the Tools and Help pull-down menus. This is a very powerful
feature for development tools creation, so I will describe how this works. When
LabVIEW starts up it does several things, which include initializing the menus. This is a
process where LabVIEW looks for files within specific directories for inclusion in the
menus. The <LV>\project and <LV>\help folders are intrinsically related to the
Tools and Help menus, respectively. When you install a LabVIEW add-on, you will
notice that new menu items are usually added to these two menus. This was achieved by
adding files to the <LV>\project and <LV>\help folders. Through a little
experimentation the nature of this process has been determined to be the following:
First, LabVIEW looks in the <LV>\project and <LV>\help folders for standalone VIs
and top-level VIs within LLBs. In the <LV>\help folder, it also looks for .hlp and .chm
compiled help files. These files are then opened when selected from the menu.
LabVIEW will look recursively
Advanced Developer Tip
through all subfolders and LLBs
There is a private VI server method called
looking for these files of interest.
Application:Menu Launch VI may be found exposed on
However, the search will ignore any
the diagram of the "Web Publishing Tool"
VIs, folders, or LLBs whose name
<LV>\project\webdoc.llb\_Web Document Tool.vi this
begins with an underscore _
property returns the last VI to call a Tools menu VI (it
character. When the search finds a file
doesnt work for Help menu), but returns it only once
of interest it will create a menu item at
then returns a null string until another Tools menu VI is
a location, which reflects where it
selected from the menu. Use this feature to create a tool
found it in the directory structure
that operates on the VI that the user launched it from, like
inside the project or help folder. For
Check into Source Code Control, or something similar.
Example, if it finds the file
<LV>\project \Goop Tools\ Rename
Goop Class.vi, it will create the menu
item ToolsGOOP ToolsRename
GOOP Class.
Here is where a twist is thrown into the naming rules. You can override the names of the
VIs, .chm and .hlp files, folders and LLBs so that they are named differently in the menu
structure from their names on disk. For VIs, LabVIEW will use the Window Title as
the menu name (this is also the VI Server VI:Front Panel Window:Title property). But,
by placing a text file with the identical root name ( RootName.vi
RootName.txt ) in the same location as the folder or file, you
can specify the name LabVIEW should use in the menus. The
name you wish to use in the menu should be placed in the text file.
For example, if you have a VI called MyBuggyCode.vi, you can
make the menu item show up as Elegant Solution by creating a
5

text file called MyBuggyCode.txt that contains the contents Elegant Solution and
placing it in the same directory as MyBuggyCode.vi.
Note that this override method works for LLBs, folders, .hlp, and
.chm files, but for .hlp and .chm files you must also add the
characters .hlp or .chm after the menu item name in the
overriding text file. The file MyCHM.chm should have an
override text file called MyCHM.txt that contains the contents
All The Help You Need.chm This will cause its menu name to
be All The Help You Need.
How does the developer use this feature, whereby they can open VIs and help files from
the menu? VIs placed in the Tools menu (<LV>\project folder) should always be set to
Run When Opened. This will cause them to look and feel like a functional dialog or
tool once they are opened after being selected from the menu.
In the Help menu, .chm and .hlp files are opened just
as if they had been double-clicked from a file
explorer window. However, the developer may want
something fancier. There is a function in the
Application ControlHelp palette called Control
Online Help. This function may be used to open a
help file and have it automatically jump to whichever
topic you are interested in by wiring the topic name to the String to search for input. If
you have one help file with several topics but want a menu item for each topic, you
would want to put a VI inside the <LV>\help folder for each topic and have the VIs call
Control Online Help with the appropriate topic argument. Just like the VIs placed in the
<LV>\project folder, these VIs should be set to Run when Opened.
Another thing you may wish to do is open an online help
document located on the Internet or perhaps a PDF file
located on local computer. NI does this by calling the VIs
<LV>\help\_browser.llb\Open URL In Browser.vi
and <LV>\help\_browser.llb\Open Acrobat
Manual.vi. If you wish to do the same, you would want
to put a VI inside the <LV>\help folder that calls these
VIs with the appropriate path or URL arguments.

LabVIEW Templates Folder

VI and control templates (.vit and .ctt files) if placed within the <LV>\templates folder
become accessible from the FileNew menu. LabVIEW gives you the option to create
a new VI or control from one of these template files in an easy-to-use menu ring style
selector that is filled with all files in the <LV>\templates folder. The use of VI
templates in the form of .vit files is not recommended for large project templates. You
can place templates as SubVITs inside of a top-level template. When a new VI is created
from the top-level .vit, a new top-level and a new subVI are opened, but you now have
the tedious chore of manually naming all of the VIs in memory and defining their
locations on disk. However, if you simply have a VI shell that you use over and over,
this may be a good option for you. The other option is to create your own development
6

tool that will copy a project folder to a new location, load all project files into memory
and then rename and relink them according to your project name. The process of
renaming and relinking is achieved by doing a Save As starting at the bottom of the
hierarchy and working upward. That being said, advanced templates are best left for a
development tool application or the next version of LabVIEW ;-)

Integrating Your Tools Into LabVIEW

I have covered many details concerning the minutia of LabVIEWs customization
options, so now Ill tie everything together. If you are creating a distribution of tools for
your organization you should do something like the following:
1.

Create the following folders:

<LV>vi.lib\ OrganizationName
<LV>project\ OrganizationName
<LV>help\OrganizationName

<LV>addons\OrganizationName
<LV>instr.lib\OrganizationName

2. Create a palette view called OrganizationName. Doing this will create a folder called
<LV>menus\OrganizationName
3. Inside <LV>vi.lib\ OrganizationName create a folder tree structure that reflects
LabVIEWs default palette structure, and populate the folders with your primitive-like
VIs, custom controls, and Toolkit-like Packages. Make sure you place these in a logical
folder location, based on where you plan on placing them in your custom palette view.
Now add these VIs and custom controls to your custom palette view. Add new submenus
where appropriate, and make all your icons look good! They should look similar to
LabVIEW-primitive icons, which are simple yet easily interpreted.
4. Inside <LV>project\ OrganizationName depending on how many tools you have you
may create a folder tree structure, or simply put all of your VIs and LLBs in the root
folder. Make sure to set the VI execution options to Run When Opened for those that
open via the menu selection. This will make them feel like a stand-alone application.
5. Inside <LV>help\OrganizationName put your toolsets compiled help file or VIs that
will open a PDF or help page on the Internet via a web browser.
6. Inside <LV>addons\OrganizationName put all the Toolkit-like packages that dont
naturally fit anywhere except at the root functions palette. These will be specific to your
company, such as a widget testing toolkit, or something like that.
7. Inside <LV>instr.lib\ OrganizationName place all of your organizations instrument
drivers.
8. Now all that is left are VI and Control Templates, Software Component Templates,
and Application Architectures. For the very simple stuff you can just put them in the
<LV>templates folder. For the big stuff, you will either have to manually copy a source
project/component folder to a new location. You may or may not have to rename the VIs
in the hierarchy, depending on if you will have more than one instance opened at a time.
Another option is to create a tool, which automates this process. That tool should then be
placed inside the <LV>project\ OrganizationName so that it is available from the Tools
menu.
Installing (uninstalling) your tools distribution is now just a matter of copying (deleting)
the above-mentioned folders into another installation of LabVIEW. Automating this is
step is easy. The user may have to manually change over to your OrganizationName
7

palette-view, but you can automate that, too, by having the installer change the LabVIEW
preferences file menuSetup keys value to OrganizationName. Thats all there is to it!
To see a working example of all of these principles in action, visit OpenG.org at
http://www.openg.org/ and download the OpenG Toolkit, which contains man-years
worth of Open Source LabVIEW tools. All this for the low price of free.
Lastly, I would like to thank Albert Given and Jean-Pierre Drolet for their valuable
feedback and input into this article. I would also like to thank the community at
OpenG.org for the content, inspiration, and feedback needed to create the OpenG Toolkit,
which was the underlying reason for accumulating the knowledge contained in this article
-- special thanks, in particular to LabVIEW Development Tools project team.