LabVIEW Idea Exchange

There seem to me to be a couple of choke points in right-click access to VIs and functions.  One is that I frequently need to use the same VI's repeatedly.  Another is that the quite useful "insert" and "replace" context items only offer a few first-tier options: one or two related palettes, or all palettes.  Try to insert a few datalog functions for example, and you have to navigate down 6 levels for each. It's even worse if you have to use "select a VI..." and browse to it. For the worst cases, insert and replace lose their advantage over copy-paste or quick drop.

 I propose a dynamically generated palette consisting of the last several VIs and functions (even controls) that have been dropped.  This is analogous to recent-commands-list functionalities common in CAD packages.

- As a member of the functions palette, the items in it are at or above the level they are in their normal place in the hierarchy.

- Since it's a palette you could pin it and it would be handy for dropping the same node on two different block diagrams

When wiring a numeric or enum to a case structure, we get the existing case as 1 (or the second enum item) and a default case also containing "0" (or the first enum item). Many times we need a special case only for one item and everything else should be in the default case.

Case structures are happy with just the word "default" in the second case. The unfortunate automatic existence of one other specific selector value in the default case hampers workflow. For example in the vast majority of my coding, I want the special case to be zero and the other case to be the default.

After wiring the selector, I could just enter the desired value in the non-default case that is showing, except if that desired value also exists (for no good obvious reason!) in the default case. If this happens, I need to edit the default case. That should not be necessary.

Suggestion: Whenever a default case is automatically created, it should not contain any extra specific selector values.

My idea is to have LabVIEW cease and desist it's self-important modal behavior.  Not that I think LabVIEW is anything other than the most important application I run, but I don't think it should force its (many windows') way to the front of the line when I shift focus to a LabVIEW window.  I didn't find any other idea that matched this, but there is this discussion that covers the notion well.

An example case:  When chasing efficiency I frequently have Task Manager open to observe CPU usage when I change front panel controls.  I'll run the .vi and load Task Manager, but when I click on a front panel control ALL the LabVIEW windows come to the front and cover Task Manager:

So, my suggestion is to have only the selected LabVIEW window come to the front.  I get the impression that Ctrl-Tab and Ctrl-e behavior are why LabVIEW controls its own window z-placement, but leaving their function out of it, my suggestion is just to change the modal behavior of LabVIEW windows.

It would be nice if you could change a selected font style by using the standard windows (MS office) shortcuts, such as CTRL-B for bold and CTRL-U for underline.  This would save many mouse clicks.

I realize that many people don't use Windows, so maybe it could be customized in the .ini file or would be dependent on what OS your are running.

When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.

It would be nice if NI added "Mouse Scroll" (and its counterpart filter event) to the supported events. Today, you can do this by using the mouse input VIs in a separate loop and polling, but that's not a very nice solution.

The default LabVIEW environment option should not show terminals as an icon. 

The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.

Yes, you can make custom probes for this behavior. But it should be native.

Currently text in an "unbundle by name" node is centered. This makes for poor readability when there are several elements being unbundled.

I think that changing the justification from center to left does improve readability.

Note 01: This apply to bundle by name as well.

Note 02: implementing this idea my gave us this one for free.

It'd be usefull for develloper and especially application user to improve graph control by adding to Graph direct access to Plot Visible property on plot legend.

For the time being, you have to go to color and choose transparent or to change visible property dynamically.

I propose control like that ... but we could find another idea to access Visible property.

Current Situation

The current commenting practice in the BD is to place free floating comment number labels and write the comment in a text field as in the example below.

Disadvantages

- comment number labels do to stick to the code block. if the code number block is moved the comment has to be moved as well.

- no link between number and comment text block

This unsophisticated way of commenting LabView code lead to the lack of comments in general. Usually a new programmer can understand what happens, but not why a function is implemented like this.

Proposal

LabView provides the Advanced Code Commenting Functions.

The comment block is more then just a text block. Basically it has a comment ID, the comment itself and a comment category.

By the context menu the following functions are provide:

1. add comment
2. delete comment
3. move comment up
       The particular comment line is moved up in the comment block. The ID is decremented
4. move comment down
        Opposite from 3.
5. highlight function
        The function to which the comment ID sticks is highlighted.
6. the comment category can be selected. (e.g.. Code Explanation, To Do, )

Adding Comments

Adding a comment in the comment block incorporates two steps (after selecting Add Comment from the context menu):

1. Sticking the automatically generated comment ID to a particular code block just by selecting the item the comment belongs to.

   This could be any type of code: wires, SubVIs, the whole Case, a particular Case, Sequences....

2. Writing the comment

If the mouse pointer is set over a comment ID the comment is shown like a tool tip and disappears as soon as the mouse is moved away.

Advantages

• Comment moves with function block if function is moved on the BD
• Comment ID sticked on the BD item and ID on the comment block always match
• generally more comments in a LabView programm through more simple way of commenting code