LabVIEW Idea Exchange

The Clean Up Panel menu option in LabVIEW 2019 messes up the labels for Image Controls. I have only noticed this with image controls that don't actually show the image.  See the attached pictures.

Before Clean Up Panel is chosen:  Notice all this vi is is the two controls on a front panel.

 After Clean Up Panel is executed.  (I had to scroll a bit to show where the labels ended up)

 I have only noticed this with image controls.  It may happen with others as well.

NXG needs an Idea Exchange.  The feedback button is a lame excuse for a replacement.  Why?

• I can't tell if my idea has been suggested before.  (And maybe someone else's suggestion is BETTER and I want to sign onto it, instead.)
• NI has to slog through bunches of similar feedback submissions to determine whether or not they are the same thing.
• Many ideas start out as unfocused concepts that are honed razor sharp by the community.
• This is an open loop feedback system.

Let's make an Idea Exchange for NXG!

There are some property nodes and methods that will fir the text in the indicator/control by resizing the control/indicator vertically.
This option is great but when you spend a lot of time organizing your front panel this option is not elegant nor suitable for your project and the user is not able to see the whole string

Like "Dequeue Element", but removes and returns the element in the back of the queue instead of the element in the front of the queue.

Like "Enqueue Element At Opposite End", but dequeues instead of enqueues from the opposite end as normal.

This would allow queues in LabVIEW to be used as double-ended queues (also called dequeues or deques, pronounced "decks"). It is already possible to enqueue elements on either end of a queue. It would make sense to also be able to dequeue elements from either end of a queue. 

It would also allow queues in LabVIEW to be used as stacks without having to use "Enqueue Element At Opposite End", which is useful when it is easy to modify consumer code but difficult or undesirable to modify producer code.

At present, using a malleable VI in almost any form alongside PPLs seems to be largely impossible.

Of course, a malleable VI is a template of sorts, and a PPL is the compiled form of some library. I can see this makes including the malleable VI impossible (at least without a predefined list of allowed types, at which point you could use the VIM as a private VI and define a set of public or private VIs, then call those from a public polymorphic VI).

However, it would be nice if we could define a VIM (either in, or alongside) a library in a project, and have it be placed in e.g. the Support destination (or specified destination via the Build Specification settings).

A quick attempt to do this resulted in the following:

• Create a library with two VIs, one outputting a number and the other a string.
• Create a VIM that has an input used only for type matching, and a Type Spec Structure for Assert Structural Match on string, int32, output the appropriate matching result type from one of the two (public, in this simple test) library VIs
• The first case of the TSS is the string one (seems relevant to outcome).
• Build the library into a lvlibp, with the VIM set to Always Included, and the destination set to Support.
• The output files are A.lvlibp, Output String.vi, Get Value.vim.
• A.lvlibp only contains Output Num.vi, not the string anymore.
• The VIM is not loadable via project (although it opens broken alone), because it calls A.lvlibp:Get String.vi, which doesn't exist.
• Get String.vi is unloadable, seemingly because it requires (perhaps it expects to be) A.lvlibp:Get String.vi...

Could this please be improved? 🙂

Ideally the VIM that is placed in the accompanying destination should link to the VIs in A.lvlibp, and none of the VIs should be missing in that PPL.

When you use Sort 1D array function, it sorts items but does not output sorted index numbers. This is a problem especially if a particular 1D subarray is used to sort an 2D array and if subarray has identical items in it. It makes it hard to rebuild the 2D array based on the sorted 1D subarray. If sorted index numbers are provided, 2D array can easily be rebuilt.