LabVIEW Idea Exchange

The current implementation of Control References on the Block Diagram could be improved. This Idea was first conceived over a year ago in a discussion on Smaller Static Refs, in the comments here.

Consider the following advantages:

1. It's generally bad style to have Ctl Refs with hidden labels. New implementation always demonstrates the label to comply with inherent self-documentation of G (just like a Local)
2. Smaller footprint combined with better visual distinction between Ctl Refs doubly improves information density
3. In general, the Control Class does not need to be shown at all times on the BD. Rather, it could be shown in Context Help (currently, CH is not useful when hovering over Controls Refs, but this is another topic), or determined by browsing Properties/Methods.
4. Eliminates the undesirable ability to rename/delete a Control Ref Label such that it no longer matches the Terminal Label.
5. Creates a better distinction between a Control Ref and a Control Class Constant (NULL Ref). The color of the Static Refs denote a "live link" with a control, while the muted tones of a Class Constant indicate no such link (NULL)
6. Complements the new LV2010 Local Variable upgrade (see image), yet remains distinct by having a different glyph, different background colors, and no directionality arrow

This idea came from customer Jason Willis during an NIWeek 2012 brainstorm session with LV developers. To me, it seemed like a good idea, so I figured I would post it to the community to flesh it out and see what kudos it gets.

When you have a reentrant VI, you have the one real VI and many clone VIs. Debugging the clones is hard. One way to make it easier might be to make the probes behave like the breakpoints do.

When you put a breakpoint on an individual clone, only that clone gets the breakpoint. But if you put a breakpoint on the real VI, all the clones get that breakpoint. That gives you a way to stop at a point of execution regardless of which clone gets pulled from the clone pool.

We could make probes do the same: if you put a probe on a real VI, any time the block diagram of a clone gets opened, a probe would be added to its wires in the same locations as on the real VI. If you removed the probe from the real VI, all the duplicate probes on the clones would go away too. But if you added a probe to a clone, the other clones would not get a probe.

I really hate having to dig through a long hierarchy of menus when I know what I want:

Visual Studio (and other MS and non-MS products) have a feature called Intellisense, which is meant to make this easier. Basically, as you type, it pops up a list of matching objects, based on context, so you can quickly select what you want:

It would be nice if LV had a similar feature - click on a property in the property node using the text tool (or Ctrl+click if using the auto-tool) and now you can type in the property name and you will get an Intellisense-like pop-up, which will have all the relevant properties.

Specific features it could have:

1. It should know all the relevant names - full names with the hierarchy (Boolean Text.Font.Color), long names (Mechanical Action) and short names (MechAction). This could probably be similar to how Quick Drop handles shortcuts or they could simply appear as separate items.
2. It should be context sensitive. If the class is Boolean, then there's no need to have Listbox properties in the list.
3. It should match all the properties which include the search string (so "in" on a boolean would match both "Indicator" and "Strings[]") and only them.
4. It should have the ability to use caps for acronyms (e.g. in the above screenshot you could use "BT" instead of "Boolean Text", similar to what appears in this video).
5. It could probably also work on the invoke node, although there it's less needed.
6. It could probably also be used to quickly select a class if you have a class specifier using the same basic mechanism.

This example (LV 2009) shows how useful this could be. You don't need anything installed. Just run the VI and start changing properties.

Caveats:

1. It will only work on the last property in the node.
2. It doesn't have the proper list of names and it doesn't implement all the features in the idea, as this is just a basic example.

Note - this is similar to this idea, but I think that it's much more usable. Also note that the second idea refers to a QDKS which ships with 2010, but that is far from perfect.

After placing a new graph, we might want to go to the plot properties dialog and change the color, label, etc. of the plots we want.

Bzzzt. No go! We can only edit plots that have been added in some other way. (by resizing the plot legend, wiring and running once with data representing several plots, etc.)

For comparison, have a look at the cursor tab. Here we can add and remove cursors at will.

My suggestion is to add the ability to add or remove plots on the plots tab properties page of graphs and charts.

It could look like in the image on the left.

Many programming languages IDE are able to distinguish the cluster level. However, selecting a cluster element in LabVIEW requires covering the full path from the top cluster until the desired element. The consumed time for this actions is directly proportional to the cluster size. It would be great that the bundle\unbundle nodes distinguish the cluster level in LabVIEW to speed up the cluster item selection.

Currently, a selection of an item requires a full navigation:

With the improvement a selection would only require partial navigation: