LabVIEW Idea Exchange

It is pretty nice that we can create custom palettes for lvclass libraries and set them as default; being able to right-click on a class wire and get an organized menu (i.e. method VIs arranged in sub-palette folders), rather than just an arbitrarily-ordered bunch of all the member VIs. 

However, it doesn't appear that the palettes inherit -- if I right-click on the class wire of a child of the class with the custom palette, I am presented with the child members and the parent members, with no palette customization.

Example

Parent Class (with custom palette)

Child class (which includes the parent members, but without the subfolder organization):

Could the IDE support inheritance of the palettes, such that right-clicking on a child class wire showed me parent items in their organized default palette view?

There is a need to have the capabilities to make comment about a type def/strict type def control (in the control editor) that are only visible in the control editor.

For instance you might want to point to the person editing the control that he/she should not rename that particular cluster element or this will brake the code (and you may want to use an arrow pointing to the element along with some text).

Currently, if you do that the comment become part of the control and is visible for every front panel instance. This bring absolutely nothing to be able to see that type of comment on the FP and it should not be seen by the user of the control (because this actually make the type def so large an unwieldy).

Therefore, there should be a need to select a group of decorations and mark them has only visible in the control editor .

Note: Right now the only way to achieve something similar to what I describe, is to put the comment in the control description, but this is no great because:

1. People tend to not expect control to have VI description.
2. This does not allow to use arrow and such to directly point  to a specific part of a control.

PJM

The ctrl+drag and ctrl+alt+drag shortcuts for adding and removing space on the BD are super awesome. But I think they would be even *more* awesome with the following tweak:

Limit space addition/removal to the visible diagram; i.e. don't make any changes to other cases in a case structure.

I have had many situations where I was doing cosmetic tweaks in one case of a case structure, only to find I have overlapping items in another case that I wasn't looking at.

Hopefully this simple animated gif demonstrates what I'm talking about.

(And yes, I know we could enable "auto-grow" on the case structure to eliminate the shrink-case-smaller-than-contents problem, but that still doesn't address all the potential issues here.)

Allow tables, list boxes, etc to be able to lock the right hand column. Currently if you resize a table or list box (or any control/indicator with columns) you end up seeing more columns. It would be nice to be able to lock the right coumn so no additional columns are displayed. Most instances of tables have a defined set of columns which will be used and it looks rather ugly to resize and end up with empty columns. The current alternative is to have code running that will do this programmatically which is a bit cumbersome. Effectively this is allowing the programmer to set a maximum number of columns.

Populating the Tree Control with items takes very long time.  I suggest improving the performance of a tree control.  Many other applications have tree controls that are populated in a small amount of time, so it should be possible with LabVIEW.

I know of three ways to populate a tree control.  The first is to individually add items using the Add Item invoke method.  This method takes a very long time.  Adding 15,000 entries took over 180 seconds.

The second way is to use the"Add Multiple Items to End" invoke method.  This took over 20 seconds for 15,000 entries.

The third way is to programatically respond to the user expanding an item in the tree and populating only as necessary.  I assume that this is fast, but it seems like a lot of work to do every time a tree control is used that could have a lot of items. Maybe LabVIEW could improve performance by using the third approach internally for the programmer. 

Currently I am hesitant to use a tree control because of performance.  LabVIEW is a great product, and making the tree control perform better would improve LabVIEW even more.

When a cluster contains refs to different type of controls that have a common ancester, the "cluster top array" primitive should be able to handle it instead of having a broken wire.

Indeed, if the lower snippet works, one can assume that it shouldn't be too hard to get the upper one to work as well when possible.

When working with arrays, it is convention that search functions output -1 when element is not found. There are several functions using this logic. I find myself quite often using "Equal" function to compare this value to -1. While not being overly complicated, considering I do it very often, it would still be nice to have function "equal to -1" which would work similarily to "equal to 0", having only one output.

Current approach:

Suggestion ("equal to -1" icon is only illustratory):

Purpose: Speeding up programming routine