Read This First

[AristosQueue (NI)]

Introduction

LabVIEW 2015 adds the ability to write VIs to modify the shortcut menus of LabVIEW's editor environment. You can add, rearrange or replace shortcut menu items for the edit-time front panel and block diagram or for the block diagram at run-time. These plug-ins do not affect the panels of running VIs -- they do not become part of applications that you build with LabVIEW. If you want to modify the run-time panel menus, use the menu editing nodes that have been available with LabVIEW for many versions.

The community website has a shortcut URL: http://ni.com/lvmenus

Voting on Plug-ins

Please give kudos to plugins that you like; we may consider adding them to LabVIEW.

Downloading Plug-ins

This web group provides a central location for sharing plug-ins with and among the LabVIEW community.

You can filter the Documents list using the "Categories" filter on the Overview page. That will help you find documents that are specifically plug-ins.

Instructions for downloading plug-ins.

USE CAUTION WHEN DOWNLOADING PLUG-INS FROM UNKNOWN AUTHORS. As with any VIs you pull from the web, use caution. Take a moment to glance at the block diagrams of the code and make sure the plug-in does what it is advertised to do.

Uploading Plug-ins Part 1: Creating Plug-Ins

Creating a shortcut menu plug-in is easy:

1. Launch LabVIEW 2015 (or later)

2. Open and run this VI:

          Windows:

     <labview install directory>\resource\plugins\PopupMenus\Create Shortcut Menu Plug-In From Template.vi

          Same path on Mac or Linux but with different symbols for directory separation.

For more information, see the help files that ship with LabVIEW.

Uploading Plug-ins Part 2: Known Issues

There is one known issue with the shortcut menu plug-ins.

Plug-ins are built from two VIs: the builder VI that creates the menu item and the execute VI that runs if the user picks that menu item.

If you use the "Data Type" property of any object in your builder VIs, you may crash LabVIEW unless you do it just right. The various Data Type properties return a Variant. If the Variant contains a LabVIEW class, this creates a strange situation where the class is loaded in the user's application instance but the data is in use in the plug-in application instance. You can safely use the various Data Type query VIs to investigate that Variant, but you have to clear all the object data out of the plug-in by the time your VI finishes running. If you do not clear all the data out, the class may get unloaded in the user's application instance leaving stale objects in the plug-in context. This is a known crash issue that we have been unable to fix without adding so much pointer tracking as to bog down the entire execution of LabVIEW. The easiest solution is to use the Request Deallocation primtive. A correct usage of it is shown in one of the plug-ins available on this web site. There are cases where the Request Deallocation primitive will not suffice to clean things up, mostly cases involving subVIs. If you have difficulties, post a discussion to this web site and we can talk about options.

Uploading Plug-ins Part 3: Submitting To This Site

When you are finished with your plug-in, you may upload it here. Go to this template and use it as the starting point for your work. The template document will guide you through the upload process.

Welcome to the community!