LabVIEW Idea Exchange

Say I've dropped two 2D array controls on my block diagram, and would like to change both of their appearances in the same way. I can select each one at a time, right click and head to Visible Items > Index Display. However, it would be nice to be able to select multiple items of the same type and have the option of applying the same change to all of them.

Currently, selecting both and right clicking lets me change the following:

It would be nice if LV could recognise that I've selected two identical controls and offer me the option of changing the display settings for each of them:

Expanding this, you could use the same approach for BD constants, such as setting multiple string constants to '\' code display, or disabling size to text.

Earlier, I posted this idea, suggesting that the error in control should not have the default value in parentheses.

Following another discussion, I now suggest an extension of that concept - No control should have the default value in parentheses. This clutters up the front panel and the diagram of the subVI.

Instead, when you hover over the input of a subVI, LabVIEW should look at it and if it's not required, should add the default value to the tip strip automatically:

This change will require us to modify all our old code if we don't want to have the clutter, but I can personally live with that. Alternatively, LV can try to be clever and do something like: "If the control isn't required and has parentheses at the end, don't display the default value".

Hie,

For the functions like 'Concatenate Strings' or 'Build Array', when many inputs are unused, you have to remove them one by one with 'Remove Input'.

Perhaps it will be easier with a tool like 'Remove Unused Inputs'.

Best Regards.

Take for example an enum that is saved as a type def. The enum has many items (let's say words) of varying length.

In order to see all of the elements, inclusive of the widest one, the array can be sized with the right-click option "Size to Widest Element".

If the type def'd enum is edited, and a longer element is added, the array of enum constants will not size to the widest element. This can be frustrating, as dozens (or more) of these arrays scattered about the program are rendered unreadable.

If the user has previously chosen to "Size to Widest Element", this setting should persist. If the user edits the enum, all of the array constants should size to the widest element.

-------------------------- Example ----------------------------------------------------------------------

If several cluster elements are hidden and we want to unhide them all, it gets tedious. For each elements, we need to:

1. Right-click the cluster...
2. advanced...
3. show hidden element...
4. select desired element...   (At this time we have moved the mouse about 500 pixels to the right in steps 2-4!)
5. click outside the cluster to deselect everything (because now the cluster AND the element are selected and we cannot immediately start again with step #1).
6. start with step #1 for the next hidden element. Tedious!

I suggest that there should be a top entry <All Elements> (or more correctly <All Hidden Elements>, but that seems unnecessarily bulky and does not really add more clarity), to unhide all hidden elements at once.

Here is how it could look like:

Idea summary: There should be a menu item to show all hidden cluster elements with one simple step (see picture).

Thanks!

Could it be possible for LabVIEW (even if only for versions 202{1,2,3} onwards etc) to make an attempt to open newer files and just break them when new features are used?

The comments in this Idea (LabVIEW Compatibility Modes) suggest this and related ideas, but it isn't the main part of that idea, so I'm posting it separately here.

An ideal solution for me would be for VIs to automatically save back in the 'oldest' version that they would support (and perhaps not be 'up-compiled' on load), but this idea has been discussed a few times and doesn't appear to be something NI will support.

An alternative (perhaps only possible in currently unreleased versions?) might be to have LabVIEW 202x try and open a VI saved in 202<x+n>, and then give the symbol for missing VIs (ideally with the name, if possible) for anything that isn't supported.

As an example, trying to open a VI using Insert into Map (if this were available for existing LabVIEW versions) in LabVIEW 2018 could produce something like

with the Context Help giving me a clue as to what was lost - I could then Google "Insert into Map LabVIEW" and try guess how I might replace it (here, probably with Variant Attributes).

I'm posting this idea in relation to some comments I've recently heard regarding sharing and packaging code with LabVIEW, and how even when other (text) languages add new features and so code using them will fail to compile, their users/developers can still open the code, try fix bits, or generally workaround issues (and evaluate the benefits of upgrading, if the changes are large).

New versions of LabVIEW continue to have significant new features, so upgrading seems like it will continue to be at least my preference, but not everyone has the same requirements/situation/SSP/blah blah blah.

An addition to the 'Find' project provider (or a standalone one) to find Parent Interfaces would be good.

I expected it to be included in LabVIEW already, but I don't see it.