Analagous to replacing wire connections with a Shift Register on a While Loop, it would be nice to replace the connector where a wire enters an In Place structure with one of the appropriate accessor functions (Unbundle/Index etc).  In the same way, it should prompt for the location on the other side of the structure, either to replace a wire connection, or to create a new element.

I would like to see the array palette to be extended.

For instance, a function that is similar to the 'find' command in Matlab. So basically an extentson of the current 'search 1D array':

1. to more dimensions (one can easily define a search order).

2. the function should return all indices where the requested value was found, not only the first one.

A further extension would be a 'find and replace' functionality.

Steven

Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.

This is how it works:

Or for example, 5 rotated copies:

Even in Color mixer simple computations are allowed:

Everywhere where I can put some numbers, in any dialog:

So, my suggestion to have the same in every numeric control or constant.

This is what I mean:

So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:

Anyway it should work everywhere, including constants on the Block Diagrams:

Also, for example, on Resize Objects Dialog:

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):

And also in Run-Time, of course, not only in Development Environment.

If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Or may be as global setting in the Options.

I am probably the only one to be using Extended precision numbers considering the feedback on these requests:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-graphs-to-display-extended-type-values-i-e-create-true-EXT/idi-p/2239078

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-All-LabVIEW-Supported-Number-Types-in-Formula-Node/idi-p/2502198

but so be it.

One other area where LabVIEW ignores extended precision is wire values in debug mode. To illustrate what I am talking about, consider this snapshot of a debugging session:

The result of my modified Bessel calculation (that reminds me I haven't suggested to implement special function calculation in extended mode...) returns a perfectly valid extended precision number, such as 5.03E+418, but LabVIEW doesn't recognise this as a valid value and returns an "Inf" value (which would be the correct reaction if the wire could only display double precision floating point values).

This wire is connected to the logarithm primitive, which happens to be polymorphic and hence accepts the extended type. The result is the correct logarithm of 5.03E+418, i.e. 964.15.

On the face of it though, it appears that the output of my VI is +Inf, and that LV went wahoo and estimated an arbitrary value of log(Inf)...

My code actually stores such values in shift registers, so when I debug problems with the code, I have 3 or 4 wires carrying an "Inf" value, which, when I am trying to understand the reason of overflow problem, is not exactly helpful.

Suggestion: display Extended Precision wire values correctly in debug mode.

Currently, when converting a longer integer type (e.g. u32) to a shorter integer type (e.g. u8), the output value wraps.

By contrast, when converting a floating point type (e.g. dbl) to an integer type (e.g. u8), the output clips.

It would be great to be able to specify the output mode for conversion to integer: Wrap or Clip!

Most fitting VIs have a mandatory input for X that is required to be the same sizes as the Y input. If left unwired, an error results, even though the x input is not designated a a required input for some reason.

Many times we want to fit a plain 1D array where the X value for each Y is simply the corresponding array index. In this case, the data and best fit arrays can be graphed on a waveform graph and we can ignore x entirely. This is now much cleaner and simpler than to construct the data for a multiplot xy graph.

Here is an example of a polynomial fit to a sine function, showing what we currently need to do. This idea would eliminate the need for the small FOR loop and associated wires:

My Idea is that most fitting VIs should assume a simple ramp if X is unwired.

(Applies to all fit function that have an X input and generate an error if it is left unwired: linear fit, polynominal fit, etc. )

Exceptions:

Fitting VIs that currently don't have a mandatory x input, e.g. "Nonlinear Fit" don't need to change, because it is up to the model to make assumptions about x. We already have full flexibility.