LabVIEW Idea Exchange

There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:

Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.

Searched briefly but couldn't find any ideas about this.

I know we have the ability #via_ignore comments to ignore specific tests for a specific VI, but I am looking at a different use case.

Here's the use case, I use DQMH. When you create a new DQMH module there is a lot of plumbing code that comes with it. It's standard stuff. Very rarely do I have to open or edit it. Much of it is scripting generated. It often fails tests but I don't care. In addition to failing, it takes up test time, which slows my feedback loop. I would a way to signal to VI analyzer to skip these files. I know I can use the VIAN API to limit the files it checks, but I was thinking there had to be a better way. 

Implementation Ideas - I had 2 main ideas

- Regex matching on VI names - with the regex pulled out of a text file somewhere ala gitignore. Many of the DQMH generated VIs have standard names, so that is easy. When generating events, they don't but you could easily add a prefix/suffix or something that the regex would pick up.

- Using the Tag API to tag the VI. I like this because the scripting can just apply the tag or apply it to the template the scripter uses. Downside is: kind of hidden from the user and perhaps if I decide to make some edits to this VI  I may want VIAN to stop ignoring it and it's not immediately obvious how to do that.

Note:

I picked the Execution and Performance Label because it didn't seem to fit any of the labels easily. If this is the wrong label and you are an admin, please relabel it.

When I was newer to LabVIEW, I found it hard to understand how people could identify front panel object styles e.g. NXG style string control vs System string control. 

I believe it is the sort of skill that takes experience and experimentation, and it only gets more complex when the appearance of the string control is customised. For example, modifying the above controls so they are the same size, they are practically identical...

I have never been able to find a good complete documentation of the differences in appearance and behaviour between different styles of front panel object - seems each style of each type of control has their quirks. So when presented with front panel objects that you did not make yourself, it is hard to 'reverse engineer' them if changes are needed. This makes it harder to learn how to make good UIs.

A potential solution would be to add a property which tells you which style a control or indicator was created as, or most recently replaced by. E.g. modern, classic, system, silver, NXG. An extension would be to add a 'reset to default style' which would behave as if replacing the customised object with an object of that style from the palette. A further extension would be to allow changing of style e.g. in this example from NXG to System via a dropdown box, although not all front panel objects are available in all styles so I can see this being more difficult to implement.

This is probably the ugliest UI mockup you will see all day but I hope it gets the idea across and sparks some conversation:

This would be accessed via 'properties' on the right click menu of the front panel object.

I'm not very experienced with XControls, QControls etc. so would welcome suggestions about how these should behave. Perhaps there is some nuance to do with styles that I am missing.

This idea is related to this one which talks about setting style for the whole front panel.

Let me know your thoughts!

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 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

While debugging LabVIEW, we often have many VI windows open. It can sometimes be difficult to manage these windows, especially once the debugging session is over. I think we can improve this situation greatly with a minor change to the All Windows dialog. This dialog (launched from the 'Window' pull-down or by pressing Ctrl-Shift-W) currently shows a list of all LabVIEW windows that are currently open:

There are several columns of information describing all the open windows, and the list is sortable by clicking a column header. You can multi-select in the list and click 'Close Window(s)' to close multiple windows at once.

Idea: If we add a "Time Opened" column that lists time stamps of when the windows were first opened, it would be easy to sort by that column, then close all the windows that were opened during a span of time, i.e. while debugging. 

While we're at it, there are several other usability enhancements that could be made to this dialog that seem to be low-hanging fruit:

• Make the window a non-modal floater, with the list dynamically updating as windows open and close.
• Add a 'Minimize Window(s)' button.
• Give useful key navigation to the 'Close Window(s)' button (and any other buttons we may add).

I know there are other ideas about making debugging easier (don't show panels, etc.). I'm scoping this idea to improvements we can make specifically to the All Windows dialog to make debugging easier.

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.