LabVIEW Idea Exchange

I realize that the DBCT is nearing its 20th birthday, and probably is not a priority for a fix, but this is so simple and has tripped up a number of LabVIEW programmers doing database applications for so many years.

The VI Rec Fetch Next Recordset (R).vi has a flaw which manifests itself in stepping past the last recordset in a multi-recordset return - then leaks a reference which causes mayhem in downstream code.  A simple test of the recordset reference would make this VI properly useful.

Among my other posts in reply to forum users about databases, the issue is captured succinctly here.

I long ago made the mods to the toolkit VI (actually, two), and reapply them with each new LabVIEW version as needed.  If anyone at NI/Emerson wants to look into this, I'd be happy to share the particulars.

Dave

A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.

This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.

This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.

When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.

The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.

Oftentimes, rearranging or reordering a Bundle by Name or Unbundle by Name for clusters can yield fewer wire crossings. For instance, below, wire crossings can be eliminated by moving "Timestamp" to the bottom of the Unbundle and "Value" second to bottom on the Bundle:

The current process of moving one of these elements:

1. Increase the size of the node using the Resize Handles on top or bottom, or select "Add Element" from Context Menu (and hope you remember if it adds and element below or above the cell you are clicking on!
2. Wire to the new element, and deal with deleting the old wire
3. Delete the old accessor using either Resize Handles or "Remove Element" from Context Menu

This can be laborious. Instead, I would like a way to quickly reorder the elements. I have a few ideas how this can be accomplished:

1. Context menu with a "Move Up" and "Move Down" action (not so elegant)
2. A pop-up window that allowed rearrangement (think "Rearrange Cases..." on Event Handler or Case Structures)
3. A native drag-and drop on the Unbundle/Bundle node itself. This could be realized given the current "click regions" on the node (hover your mouse and sweep horizontally over one of these nodes... you'll discover the 4 regions). The two "Arrow" regions currently move the node on the BD, but they could be used to rearrange the node (see below)

Just throwing out some ideas, I'm not stuck on any one. So, the idea you are voting for: Provide a User Interface for quickly rearranging elements on a Bundle or Unbundle by Name.

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

Idea expansion:

• Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

Open the VI Properties dialog when the Control key is depressed and the VI's icon in the upper right is double-clicked.

Right-clicking the icon shows a pop-up menu with VI Properties, Edit Icon..., and Find All Instances. Double clicking it opens the icon editor.

I've been doing a lot of string comparisons lately and I really hate having to drop To Upper/Lower Case function in front of my Equal? comparisons, as shown below:

It would be so much nicer if I could just have a special Case Insensitive mode for the Equal? node (and, it would be nice if the Equal? function changed its visual appearance, somehow, to signify that it is in a Case Insensitive mode):

I wish there was a boolean text specifier for Format into String functions.

% followed by "?" would expect two possible strings like this. Why not?