LabVIEW Idea Exchange

I have a rather large string indicator for displaying operator messages/alarms

and I would like to have the option for an automatic vertical center of the text,

so that all messages get displayed in the center of the screen (if too many lines, justify to top and display the scrollbar).

I also have a 2 line statusbar, but displaying a 1 line message that is not vertically centered, looks very strange.

The work-around I'm using now is to display the multiline string centered in a picturecontrol,

but I'm not a big fan of this fix because there are many boundary-conditions to keep in mind ...

Another annoyance is that to prevent selection of text in the indicator I often disable the indicator

(it looks unprofessional if an indicatortext can be selected in the GUI),

but if the displayed text is larger than the string indicator, the scrollbar is also disabled !?!? 

and therefore not controllable by the user

I find often the need of creating array indicators with many elements, and of labelling them is a way which allows easy identification of the element index.

Normally the labels of the elements can be made visible, like in the left example shown:

One way of doing it, if the array has a fixed size, and all of the array is shown at once, is to juxtapose a set of text labels identifying the elements. Tedious to build.

If the array changes size, if it is larger than shown, if it is supposed to be scrolled on the FP, static labels are useless. Currently the label of the element can be made visible, but all elements share the same label. The index display of the array can be shown, but it relates to a single element, which makes cumbersome to identify elements of long arrays.

I usually resort to more sophisticate contraptions, like arrays of clusters, each composed of the element in question and of a numeric indicator; or to two parallel array indicators, one for the elements itself and one for the indices. Both solutions are more cumbersome to build and to size and align equally; the index content has to be prefilled and maintained in sync when array elements are added or deleted (programmatically or via contextual menu); in the second case, a lot of events have to be trapped programmatically, for instance to maintain synchronism when the main array is scrolled.

What I would like to have is an additional label natively visible, showing the element index, like on the right.

The labels could be made optionally visible with a contextual menu ---- left click->visible items->index label.

Options (perhaps properties) in order to set the value of the first element (e.g. 0 or 1 or any other value) and the step value if different than 1 would also be useful. Standard options about location and orientation of the label with respect to the array element would apply.

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.

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

Swagger/OpenAPI  has become the default go to way to document and interact with rest API's.  It would be great that when you publish a LabVIEW webservice it generates the OpenAPI yml or json file (being able to generate both would be great).

Also having a right click in the lvproj webservice view that brings you to the swagger page for debugging would be helpful. 

On bigger projects, when creating a new class, I find it time-consuming to track down the parent class I'd like to inherit from.

It'd save me some pain if there was some kind of filter and/or search option for this on the New Class GUI:

Other thoughts on this:

- While the tree structure is useful, I usually know the name of the parent class I want to inherit from, but I don't necessarily know the full inheritance of it, meaning the tree structure isn't the most efficient way to find it.  (Even alphabetical by class name would be faster in these cases).

- I'd find the tree structure here easier to follow if the lines were visible.