LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Suppose a front panel contains the three elements seen below, with the first one being selected.

1 (edited).png

In the situation above currently pressing Tab does nothing. It would be useful if, instead, pressing Tab would cycle the element selection to the next element in the tabbing order, as seen below.

2 (edited).png

If Tab was pressed again, it would cycle to the next element in the tabbing order, as seen below. And so on.

3 (edited).png

Notes

This idea would speed up development by enabling us to cycle through element selection without using the mouse.
When used in conjunction with the F2 idea, this would enable us to use Tab + F2 combinations to quickly cycle through elements and rename their labels and/or captions.
This idea could be extended to terminals on the block diagram. Suppose a terminal is selected on the block diagram, pressing tab would navigate to another terminal on the block diagram.
I'm aware that currently it is possible to use Tab or Shift+Tab to cycle between elements forwards or backwards when the VI is in Run Mode (Ctrl + M). While that is useful, this idea asks for more.

Thanks!

View All (3)

I searched reentrant in this idea exchange and didn't see anything on it so here goes. I would like some sort of indicator showing that a VI is reentrant. Right now, as far as I know, you have to go into the properties and check. It would be nice if there could be either something on the icon, or a small label that would show if the VI was reentrant. Or maybe a slight "halo" around the VI, something to that effect. Any other ideas on how to do this are welcome.

Message Edited by for(imstuck) on 02-24-2010 10:00 AM

View All (1)

DVRs are references, and are automatically released when the VI hierarchy that created and "owns" it goes idle (stops executing). Commonly, the DVR just contains by-value objects, or LabVIEW references that are also automatically released, but an important use case of DVRs is wrapping a non-labview reference that must be properly cleaned-up. An example is an SQLite Connection pointer that must have a dll method called on it in order to release the database file it is holding open. Many dlls have similar pointers/handles that need to be properly closed. This is a headache for Programmers, who cannot rely on a stopped VI releasing its resources, often requiring restarts of LabVIEW to unload the dll.

A clean and easy solution to this problem would be to allow a "DVR Cleanup Callback VI" to be registered with the system when the DVR is created. That VI would be called if and only if the DVR is release because its calling VI hierarchy goes idle. This VI would contain the code to cleanup/close the contained non-LabVIEW references. Could have other uses, such as debugging.

I have developed multiple APIs that wrap non-LabVIEW dlls, and this feature would be a very significant help. Please consider it.

View All (1)

Who has ever made a cluster typedef, then added some elements, then added more, then a little more? Have you noticed the "typedef explosion" of your block diagram as a result, with constants overlapping other code? Make a right-click option to "link" a bundle by name to a typedef. Note that the two pieces of code below would be identical, but the bundle on left would not suffer from typedef explosion. In addition, have a selectable menu

Another idea is to link the bundle to the destination:

View All (2)

Wire Anchor Point / Wire Bends

For most functional blocks on the Front Panel, the wire anchor point is very near the edge of the block (reference this idea for an exploded view of the wire anchor point). This lends itself very well to a trick I use to achieve neat parallel wire routing (until this idea is implemented!😞

Step 1: Wire up a bunch of parallel wires, and you've got a mess!

Step 2: Grab one of the functions, and drag it all the way up and down so that the parallel wires all bend along the same line

Step 3: Grab the wires one at a time, and using Shift+Arrow Left or Right and distribute so that the vertical wire runs are evenly spaced

Here's the problem: Bundle by Name, Unbundle by Name, Property/Invoke Nodes, Local Variables etc. have the "wire anchor point" in the center of the node. This makes the above trick difficult, and it also presents more problems:

Frame 1 shows erratic spacing of tunnels, and a highlighted wire that lands in the center of the large Unbundle by Name. I have drawn a red line that shows the center of the wire run as currently implemented, and the green line shows where I propose the wires should bend. Frame 2 shows what you see when check "Hide Full Names": the wire bends are clearly evident and easy to fix, as shown in Frame 3.

Another problem is "what you see is (maybe or maybe not) what you get":

The three tunnels appear to be wired to 6, 7, and 8, but indeed they are actually wired to 1, 5, and 7.

In a nutshell: When the location of a wire bend is calculated, it should bend halfway between the edges of two nodes. This could be accomplished by placing the wire anchor point at the edge of the node instead of the center of the node.

View All (7)

Shared Icon Editor Glyphs Directory

So at the moment LabVIEW has the icon editor glphs stored in the following location.

<username>\Documents\LabVIEW Data\Glyphs

This is fine, until you login as another user. Then you realize all of your icons are gone because LabVIEW installed the icons for the user that was logged in when LabVIEW was being installed.

Similarly a problem exists if I am distributing icon editor glyphs of my own. I have a reuse package with a bunch of useful icons, and I have VIPM install them to that users folder. The problem is if I login to a machine remotely, and perform the update as my user, then those icons are only installed for that user name, and not all users.

What this idea is for, is to have a shared folder for icon editor glyphs, which is used for all users on that PC. Some place like

<LabVIEW Install>\Resources\Icon Editor Glyphs

would work, or...

<ProgramData>\National Instruments\Icon Editor Glyphs

Then icons can be installed in one folder, and be shared for all users.

Comparison Palette Better order

View All (4)

New build option: Service

It is fairly common to build applications in LabVIEW that are useful to run as a service (monitoring software e.g.) , however to do so today you need to "cheat" and use srvany, and write and run batch files to get it installed.

It would be great if we could build real services, and the installer would take care of the installation process. You could even have a nice template for services with an accompanying user interface client, with notification icon and everything.

LabVIEW everywhere...Not just on different targets, but in every part of the system. 🙂

The Open/Create/Replace file I/O primitive is pretty powerful. It will check to see if the file is there for you, and, if not, create a new one. I use the "Open or Create" option often when generating multiple delimited text files in long term tests. When a new file is created, I need know so I can add a header, and I need to skip the header operation if the file is being appended. Sure, I could check to see if the file exists before trying to open it, but then wouldn't that just make the power of the Open/Replace/Create function redundant? Some operation took place based on my input to the "operation" terminal, and whether or not the file exists. Unfortunately, I have no idea what that operation was, because the function doesn't tell me. Let me know if the Open/Create/Replace function created a new file so I can add my header.

This is not without precedent. For example, the "Obtain Queue" primitive has an option to create a new queue if a queue of the given name is not found. It let's you know if the new queue was created:

View All (4)

View All (3)

Copy and Paste-Replace

This is just an idea I had while working on a simple application. I often find myself wanting to replace multiple objects on a block diagram in a repititive manner. As an example, I have an application that uses a queue requiring an enumerated value as an input - when I started the application I didn't use a type definition, but I (of course) quickly arrived at a point where I needed to replace all of my constants with a type definition.

Right now I have a few options:

1) Delete the type definition and drop a new one down and wire it up

2) Right-click and select 'replace' and point it to the ctl file

both of which take a considerable amount of time to do over and over again.

Here's my idea... I create the type definition once, and press CTRL+C while it's highlighted on the block diagram. Then I select one (or multiple) items that I want to replace with this type definition and when I press CTRL+P it automatically replaces and wires the item in the copy buffer.

It's hard to illustrate, but I just wanted to throw it out there to see if anyone likes the idea.

View All (4)

View All (1)

Whenever I place a Bundle By Name (or Unbundle By Name) function on the block diagram, it is configured to Show Full Names. But while creating the cluster, I provide descriptive names to each element and so I want that every time when I place the Bundle By Name (or Unbundle By Name) function on the block diagram, by default it must be configured as Hide Full Names.

Unbundle function

I know, my wish is not what everybody else wants to have, so better solution to this could be a selectable option (perhaps categorized in Environment setting).