LabVIEW Idea Exchange

I would like the ability to enter simple equations in numeric controls and constants. Pressing return places the answer in the control or constant.

I would like to introduce a little shorthand for creating numeric constants with non-decimal radix.  New constants should be able to autoadapt for radix, much like they do for type:  Drop a constant, enter '0x20' or 'x20' to get a constant with Hex radix (visible!), and the proper value.

In addition, it would be nice if automatic conversions would take place if radix specifiers are entered into (non-hex) constants (or controls).  For example, entering '0x20' into a numeric control with decimal radix should result in a value of 32 being entered (auto conversion).  Hex is an exception, obviously, because b and d are already valid.  The other radices have no such problem.

Problem

Many times, the bulk of LabVIEW development happens on computers that will never interface with hardware. A dozen engineers may be collaborating on code that will ultimately run on a dedicated machine somewhere, that is connected. Yet, as things currently are, I have to install more than I need on my development machine to get access to API VIs. If I am working on my laptop on an application with DAQ, RF, Spectrum analyzer, etc. components, I have to choose to either download and install all of that, or deal with missing VIs and broken arrows. This seems needless, since my particular machine will never actually interface with the hardware.

Idea

I would like to have the option to install only the LabVIEW VIs and ignore the driver itself. In many, if not most cases, the LabVIEW API could be independent of driver version. It could install very quickly, since it would just be a set of essentially no-op VIs. I don't care that the VIs would do nothing. They would just be placeholders for my development purposes. This would allow me to have full API access to develop my code without having to carry around large driver installations that I will never actually use.

Hi,

Following this forum thread, I post here my idea:

https://forums.ni.com/t5/LabVIEW/Modern-embedded-web-browser/m-p/4209271?profile.language=fr#M1219530

Is it possible to update the embedded web browser in order to comply with HTML5 ?

We uses external web pages to improve the user experience in out LabVIEW applications.

Regards,

Amaury

Title says all. Can't believe it was never proposed; if it was, I couldn't find.

Missing that, I have to that programmatically, but it's always a detour:

Should be quite easy to change the property page like e.g:

(6 colors for system booleans, 4 for all others, as known)

I like to collapse long string and path constants to consolidate diagrams.  Showing the string or path value in the tip strip is useful but tedious to update.

I suggest an appearance property that would automatically display the current value in a tip strip for string and path constants.

This property would be most useful if the Block Diagram Options page was also modified to allow a global setting.

Wouldn't it be nice if Probes window had a drag'n'drop reorder functionality, maybe even a Sort?

Often you (I) place a couple of probes, maybe add some in another VI and then go back and add one earlier in a block diagram. 

Is this a problem? Well, it's not breaking, but i'd like probe 1 to be the earliest executed probe and so on. Often execution order can easily be something like 13, 19, 3 and drag'n'drop #3 below the #19 would the shift them as 3, 13, 19. (Similar to how Reorder Case works)

It'd be nice if you could drag this probe in the probe window and it'd change numbers accordingly (switch/reorder within the VI).

Maybe even have Sort button that simply renumbers all as they're shown in the probe window.

It's somewhat similar, but different, to Altenbachs switcheroo idea: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probe-switcheroo/idi-p/3126138

I'm not sure if this idea already exists, at times i wish to have an option to display the line numbers in a string control/indicator/constant.

One thing I love with LabVIEW is to be able to execute the same source code on multiple targets (Win, Linux, NI Linux RT, etc)

I use Linux more and more to deploy my LabVIEW built apps and now instead of VM I use Windows Subsystem for Linux (WSL) on Windows 11, in very few steps I can create an Ubuntu instance, add a desktop and xrdp and then remote desktop into it.

What would be fantastic is to not event need a desktop and xrdp but just install LabVIEW in the WSL instance via terminal and then run LabVIEW on Windows and select the WSL instance as execution target as I would do for an RT target.

Currently if you flush an event queue that data is lost. Flushing and destroying and event queue should have the same interface as flushing/destroying a normal queue. Return the Data! I want the option to batch process the events, The code below would have to handle 1000 separate events to get the data out.

Idea
Flush Event Queue.vi should return remaining event data.
Destroy User Event.vi should return any unhandled events.

Hi,

i propose to add a "Key Focus" event for each control. We already have Mouse events (leaving, entering) - but when the user (or the programmer) prefers the keyboard (with proper tabbing setup) you have to poll each interesting control for it's "Key Focus" property to initiate a user event...

So please:

Add a "Got Focus" (and additionally a "Lost Focus") event to the event structure!

I'm developing code, and like most people I know, I have multiple VI's open at once.

If I then go and open the VI properties dialog, I lose track of what VI the properties are for, especially if I get an interruption.  I know I can just close the properties window and open it again for whichever VI I wanted (or go to the parent category to see the name), but this could be solved by simply adding the name of the VI to the window title of the Properties dialog. 

like this:

I tend to use malleable VIs more often than half of the items in the "New" context menu list when you right-click within a project, however, it's not an option:

Instead, I either need to:

- Create a new VI and then make several property modifications, and save it as a ".vim".

- Create it through the file menu and then remember that I need to move it to the appropriate place in my project, because it gets created at the top-level.

Why not include this in the context menu?  (Bonus points if Polymorphic VIs get added too!)