LabVIEW Idea Exchange

It would be nice if the Strip Path function had a recursive option rather than having to string Strip Paths together or use an external loop.

 eg change from this:

to this:

regards

Ray

What if I had this:

Then I wanted to insert something with similar terminals:

I'd end up with this:

But the Error terminals aren't wired! So maybe I should be able to select both wires:

Then Right Click » Insert Write Node:

Then I'd have this:

How easy would that be!?

One of the most over-looked LabVIEW VI Properties, mentioned in all of the "Good LabVIEW Coding Practices", is the one called "Documentation", where you describe what the VI does, and its Inputs and Outputs (at a minimum).  [NI Examples are certainly guilty of this].

I've been trying (and mostly succeeding) to ensure that every VI I write has such Documentation.  Sometimes I make a mis-type, highlight "bad" parts, and hit the "Delete" (or backspace), then say "Oops, erased too much, let's undo that with ^Z".  Except there is no Undo, or at least it isn't bound to ^Z here.

I can find no other place in LabVIEW that doesn't allow ^Z to replace deleted text.  It works in String Constants, in Labels (whether Free Labels or names for Controls/Indicators), and other places.

To encourage LabVIEW Developers to use the Documentation property, can you please allow us to "undo a boo-boo" with ^Z?

Bob "Imperfect" Schor

I can't count the number of times I've seen this dialog :

Of course I want to continue, that's why I right-clicked the structure and chose Remove [Structure]!  This dialog must be a holdover from pre-Undo days.  Do we pop-up a dialog when you select your whole diagram and press <Delete>?  What about when you press Ctrl-B?  These actions have the potential to remove just as much diagram content as Remove [Structure].

Please get rid of this dialog, and just let us Undo the operation if we need to, just like we do all the other potentially destructive diagram edit operations.

As mentioned at the end of my comment here, editing text is a bit clumsy. There should be a text toobar that is similar to what we can find in any other application.

Maybe it could be dynamic so it only appears when editing text.

Here's the quote from the other thread:

One thing that should be improved is the font pulldown which feels so early 1990's. When working with text, we want a text toolbar like anywhere else, (even in the post editor here in the forum!) with a bold, italic, etc. buttons, font and size rings, etc. You know what I mean!

Today, the enum data type in LabVIEW only allows having sequential numeric values (0, 1, 2, 3, etc.).

It would be very useful to have sparse enums, meaning enums which can have custom numeric values assigned to their strings, just like you can do today with rings.

If you want an example where this will be useful, think of error codes - this would allow you to use an enum on the diagram to select the error, or in a case structure.

Add new features, flexibility, and new controls to the Front Panel.  The only new controls I've seen were made by LabVIEW Customers, and although they were great, they were not resizeable without being distorted (bitmap).  I think it's time for NI to give more options and features for the Front Panel Controls.  I attached some suggestions.  They are there for example, so don't focus on the controls I've made, but the idea of improvements I am suggesting.  NI has done a great job on the Diagrams.  I should hope it's time NI improves the Front Panel.

NI has a private method for returning the hWnd of a VI but there is no "publicly" available method for this. The private method is already shared around forums and used extensively as interacting with the Win32 APIs is a common need for advanced UIs. The appearance configs for VIs only work relative to other VIs and trying to develop LabVIEW based applications that are used alongside other applications presents many roadblocks, even with other NI software such as TestStand. (TestStand has an API method for getting the hWnd!)

The other method commonly used is to also use the Win32 FindWindow call however this presents issues if there are multiple windows with the same captions (easy enough with Cloned VIs) and is not a robust approach.

I propose that Case Selectors should accept any type of reference, and the two cases generated are "Valid Ref" and "Invalid Ref". (This would be very similar to the current behavior of the Case Selector accepting errors with the two cases of "Error" and "No Error".)

The current behavior using "Not a Number/Path/Refnum" is very unintuitive. It requires the programmer to use Not Logic (i.e., do something if the reference is "not not valid").

I'd like the ability to set the target version of LabVIEW when I use the Save, Save All, etc commands.

A similar idea exists here: LabVIEW Compatibility Modes, but that idea focuses on retaining the existing version of a VI when it is opened, assuming no newer-LV-version-requiring changes are made.

I'd like to (additionally/instead) be able to choose from a dialog box/enum/etc which version my saves should target (older than the current version of LabVIEW I'm using).

Essentially, this is just the Save for Previous as a possible default save (with the default target being the current version). Since you can't Save for Previous on top of the code you have in memory, I think it would be nice to have this option.

When I want to select a given index of an Enum (Index, not String value) then it can be cumbersome.

I can make the digital display visible for the constant or control, but when the drop-down list appears.... yeah.

Can't we include the Index on the left side of the drop-down list (Spot my numbering error)?

It's not too hard here because they're sequentially ordered (more or less) but we have some enums with over 100 elements which are not so nicely ordered. Sometimes we just need to find out which element corresponds to a given index, or to select a given index directly. This is not so easy manually. I know we can enter the value for a constant in the DigitalDisplay area to select that element, but I still feel it would be nice to include the index when showing the selection list.

This is useful anywhere there is an Integer to Enum conversion (or the opposite).