When LabVIEW 2013 released, I was really excited about LabVIEW Bookmarks. I've been using them for a year now, and I feel they are one of the most productivity-enhancing features in the whole product.
What are bookmarks? Any word preceded by a "#" symbol within a free label, object label, wire label, or subdiagram label on the block diagram. So they're super-easy to create (you just type!), and also very easy to manage with the View > Bookmark Manager window. And my favorite (often-overlooked) aspect of the Bookmark Manager is that it will parse all of the VIs in your project for bookmarks, even VIs that are not in memory! In my opinion, that's the primary benefit that the Bookmark Manager provides over the standard Find window.
After using bookmarks regularly over the past year, I have discovered three distinct use cases where they come in handy:
To-Dos - This one is probably pretty obvious, but whenever there is a section of code that you know you'll need to revisit, stick a #todo bookmark there and use the Bookmark Manager to come back to it later.
Benchmarking - When I'm investigating a large app for performance improvements, I'll often make tweaks in several places to try to speed things up...turning on inlining, setting reentrancy, parallelizing For Loops, etc. I leave bookmarks (#inlined, #reentrant, etc.) where I make these changes to make it easy to come back to them later if necessary.
Code Review - I have a colleague with whom I've been doing frequent code reviews, and he's a Bookmark Believer too. It is so nice to arrive at his desk for a code review, and to see the Bookmark Manager already open on his screen, with #review bookmarks ready to go through, outlining all the changes he made.
So if you have LabVIEW 2013 or later, you should really start using this great feature! One final note...if you are using the Bookmark Manager to navigate through code that ships with LabVIEW, you might want to add these INI tokens to your LabVIEW INI file:
BookmarkManager.ShowVILIB=TRUE (LabVIEW 2013 and later)
BookmarkManager.ShowRESOURCE=TRUE (LabVIEW 2014 and later)
Without these INI tokens, the Bookmark Manager will not show bookmarks in VIs that live in the [LabVIEW 20xx]\vi.lib or [LabVIEW 20xx]\resource folders. Obviously I need these tokens for my work in LabVIEW R&D, but I can think of use cases where other LabVIEW developers might need to navigate bookmarks in shipping LabVIEW VIs as well.
Wednesday, October 8, 2014
Thursday, August 14, 2014
It's fairly common in LabVIEW applications to display the front panel of a subVI in order to retrieve inputs from the user, or to just display information. Unfortunately, there are several "gotchas" associated with this seemingly simple use-case. Follow these steps to ensure your modal subVI panel functions properly.
- Handle the opening and closing of the subVI panel programmatically. You may be tempted to use the SubVI Node Setup right-click option on the subVI to easily display the subVI panel when it executes:
The biggest problem with using this option is that your subVI is not allowed to run any initialization code before displaying its panel. If your subVI needs to move/disable/hide controls and indicators, you have no control over when it is "safe" to display the subVI panel when using this option. So instead, use the FP.Open method to display the subVI panel once you have initialized it, and use the FP.Close method to close it once the user dismisses the subVI dialog:
- Configure the VI Properties of the subVI properly. You'll want the Window Appearance in VI Properties to be set to "Custom", with custom settings like this:
Note that the menu bar, title bar, and scrollbars have all been hidden. Also note that the Show Abort Button option is disabled...this is so a user can't abort your entire application by pressing Ctrl-. while your subVI dialog is active. The Window Behavior is set as Modal, and note that the Show front panel when called option is disabled, to avoid the same issues described in point #1 above.
- Call your modal dialog subVI dynamically. Whenever you run a VI, all of its statically-called subVIs (i.e. normal subVIs sitting on its diagram) are reserved for running. This means that none of the subVIs are in edit mode, since they may be executed by the top-level VI at some point. An unfortunate side effect of this behavior is that any reserved subVI that also has a modal window appearance will be immediately displayed if its front panel is already open. And since it is a modal window, you cannot dismiss it (since it's not running, it's just reserved for running). The best way to avoid this problem (other than always making sure your modal subVI panels are closed before running) is to call the modal dialog subVI dynamically:
By changing the subVI to Load and retain on first call, it will no longer be reserved for running when you run the top-level VI, and as a result, will not ever hang your app if you accidentally leave it open before running.