LabVIEW Idea Exchange

Currently LabVIEW only has support for Mandriva, RedHat and SUSE Linux.  What's even worse, only 32-bit versions of those are supported.  Today, 64-bit linux installations are on huge raise, and Ubuntu is getting more and more popular.  LabVIEW Linux support should be expanded to include Ubuntu, and 64-bit versions are needed.

cheers,

Pekko

If you have a local variable and you either rename it's control/indicator, or you click it to change it to refer to a different variable, all local instances resize based on a centre justified behaviour, which can have undesireable layout issues.

For example here is a what happens when it's made longer next to the bounds of a case structure.
(The Boolean is provided to show how it's aligned, and also to show it resized the case structure).

If the local variable were Left justified as a 'Write' type (expands to the right when changed) or Right justified when a 'Read' type (expands to the left when changed) it wouldn't make such a mess of things!

The error ring control is awesome having its parameterized input strings which supprots things like %s, %d, and %f to customize your error string.  This is not supported by the error ring when you are defining the string in an external project erorr code file however, and that is a problem since you then can't localize for multi language from external files.

This idea is to add parametrized inputs to the error ring for ALL errors, custom or loaded from project resource files.

see screenshot below.

Whenever I built something (executable, installer) I want to go to the output location to change some filenames for distribution (e.g. I change "volume" folder of the installer to contain the name and version in the program name), zip things up to post on the server, etc.

On the final progress screen, where it tells me that the built has finished, I would like an additional button to open the target folder location(s) in explorer (similar to e.g. when downloading a file using IE) while dismissing the dialog.

Right now it says:

"The build is complete. you can locate the built at <very long and hard to remember path spread over 3-4 lines and that cannot be coped/pasted from this dialog anyway>."

Well, if the builder is smart enough to know where things are, why can't it just directly take me there as an option? 😄

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!

Currently, XControls do not trigger ("wake up") for dynamic events, even if the event structure is registered for them.  My suggestion is simply that they do.

I'd like to be able to delete an object from an existing wire and then have that wire be automatically reconnected.  Currently a broken wire is left after deleting something and one must manually reconnect the wire.  This would be the opposite of the popup option to Insert something.  Some deletions may produce a maze of broken wires that would be difficult to determine what to auto-reconnect but perhaps situations where there is only one broken wire (for example removing a Numeric Increment function (+1) from a wire) could be handled.

I want to be able to work on STABLE versions of LV.

The last great stable version I remember was 6.1 (I never had 7.1).

2009 and 8.5.1 were not bad but please give us a feature-fixed long-term support version of LabVIEW.

For anyone unfamiliar with the idea, many Linux distributions offer the same:  Here's a link to the Ubuntu webpage outlining THEIR LTS strategy.

Shane.

One improvement that I can see helping both idea suggesters and moderators: Help us know the scope of potential LabVIEW change.

Many ideas here are marked complete because they've been implemented in NXG. (Samples 1, 2, 3)

The message I get from this status is, "That's a great idea. We'll put resources toward making our next-generation product do that awesome thing, but it's more work that we want to do on the current generation product."

Many others are marked declined because significant changes to LabVIEW aren't planned (presumably in consideration of end-of-life). (Samples 1, 2, 3)

The message I get from this status is, "That's a great idea, but it would cost us more than we want to put into our current-generation product."

I think both of those messages are totally valid, but I find myself increasingly reserved about suggesting ideas here because I don't know where those thresholds lie. Could the community receive some guidelines on what type of change might make it into LabVIEW? If we had those guidelines, we could save our own time by only suggesting things that might make it in and we could save the moderator's time by reducing the number of ideas to have to process.