LabVIEW Idea Exchange

Hi, I do a lot of UI work with LabVIEW, and I'm finding over and over that when you have an array of clusters, the appearance is still to "fat".

I'd like to see a very thin border for Arrays and Clusters.

If you look at the "Simple String" control, this is exactly what I mean. It's a single pixel border.

Maybe like this:

Change the VI Properties Dialog to be able to reach the desired option with a single click, Instead of using the drop down menu.

It will be more clear and fast to access properties. 

LabVIEW's case selector icon (?) is taller than tunnels, so it interrupts wiring flow whenever a standard VI (4-2-2-4 terminal configuration) uses one of the terminals as the selector and an adjacent terminal is also wired as a tunnel.  I'd like to see the case selector be the same height as a tunnel.

When do I use the Run Continuously button?

Almost Never. And most times I hit it, it's an accident and it's a pain.

PLEASE hide it by default on all new VIs.

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.

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 ----------------------------------------------------------------------

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.

This idea started when I realized the WebDAV API provided by NI does not have the ability to read the File Creation information on a remote file.

"That's okay" I thought, I'm a programmer and will add it myself.  Looking at the source it looks like NI just leveraged someone else's protocol, and wrapped it into some Call Library Function Nodes.  NI could have written the WebDAV API wrapping their own HTTP API functions, using G instead, allowing for customization but they didn't.

"That's okay" I thought, I'm a programmer, and I'll look into recreating the WebDAV API, by calling the NI HTTP API.  Looking at the source sounds like NI didn't implement all of the HTTP functions available, only the most basic ones.  And since WebDAV requires more than just the PUT, GET, and POST, that means also having to update the HTTP API to have those functions, so that I can rewrite the WebDAV API.  Oh but look at that, NI also just (seemingly) wrapped someone else's implementation again into Call Library Function Nodes, this time calling the ni_httpClient.dll.  NI could have written the HTTP API wrapping their own TCP primitive API functions using G instead, allowing for customization but they didn't.

So this idea is for one or more of the following things, from the easiest, to the most difficult.

1. Add the File Creation Date, as returned information from the Get File Info of the WebDAV API.
2. Implement the WebDAV API in G, and eat your own dog food.
3. Implement the HTTP API in G, and eat your own dog food.