LabVIEW Idea Exchange

When manually analysing a project, we can set the target in which the VIs should be loaded. Unfortunately, VIs with RT code are often broken under windows, leading to wrong test results, or even worse, pop-ups asking for VIs.

Please add an Application Reference Input for the VIAn Run.v.

Maybe this option could also be useful set in the VI Analyzer configuration file?

Currently, the Third-Party Licensing and Activation Toolkit doesn't handle PPLs. This makes creating a plugin, pay-per-component architecture difficult.  Handling licensing and activation of PPLs is needed as part of TPLAT or some other mechanism.

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

When using LabVIEW in combination with other languages, it would be really nice for LabVIEW to be able to read from and write to the stdout and stderr streams. For example, when writing a dll in C that is to be used by LabVIEW, it would be really nice to be able to see the output and error streams from within LabVIEW. As it stands you have to jump through hoops in another IDE or create a log file or some other workaround if you want to see what might have happened inside the dll to cause it to crash.

Codewars - Achieve mastery through coding practice and developer mentorship

What language is missing in this list??

Codewars for LabVIEW should be mostly community driven, but NI would have to set it up.

Swagger/OpenAPI  has become the default go to way to document and interact with rest API's.  It would be great that when you publish a LabVIEW webservice it generates the OpenAPI yml or json file (being able to generate both would be great).

Also having a right click in the lvproj webservice view that brings you to the swagger page for debugging would be helpful. 

I would be helpful if the Python nodes supported Python Virtual Environments. One of the powerful features of Python is able to setup multiple separate environments on a single computer, it would be LabVIEW's Python integration could also leverage this. TestStand already does have this capability, so hopefully it could be quickly/easily leveraged into LabVIEW. 😁

The concept of fluent interfaces using method chaining applied to a LabVIEW block diagram would be awesome!

When calling .NET libraries from LabVIEW, block diagrams explode horizontally - the aspect ratio of the diagram can easily push 5:1 or worse (it's 10:1 in the example below). Some Method Chaining syntactical sugar would yield a more space-efficient-and-readable 4:3 to 16:9 or so.

Property Chaining is already well-established in LabVIEW - let's get us some Method Chaining!

See the first comment for footnotes...

Software development has moved on since a similar idea was declined in 2016

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-LVdiff-and-LVMerge-available-for-all-labview-vers...

I would like to suggest just LVCompare is made available in all versions of LabVIEW.

If LVMerge was also available that would be great, but leaving in just in the Professional version would also work.

As a lone developer I use GIT even on very simple projects to give me the ability to rewind and see what changes I have made. Projects are often put down and picked up weeks later. LVCompare lets me see how far I had got. Its also very useful for picking up debugging that should have been removed. In short Software Version Control just make my life easier.

If you have mulitple versions of LabVIEW installed, some of them show up in the "Open With" menu, but regardless of which item you select, the VI will always open in whichever version of LabVIEW was opened most recently.

Example: if I opened a legacy VI in LabVIEW 2009, closed that version of LabVIEW completely, and opened another VI using the "Open with" menu and selected LabVIEW 12..., LabVIEW 2009 is relaunched and is unable to open the VI because it should have launched in LabVIEW 2012.

The current workaround is to add all installed versions as options in the "Send to" menu, but this is not nearly as intuitive as using "Open with" would be.

Currently, when you programmatically build an application using the "Build" VI of the App Builder API, you have no feedback (such as build details, progress percentage, warnings, errors...) and no ability to cancel while it builds.

So you have no idea how long it will take to build and cannot cancel if it takes too long.

It would be great to have these interactions, just like with the manual build:

The Build VI could have 2 notifiers or user events as additional inputs:

- 1 to receive build details, progress percentage, warnings and errors

- 1 to send the Cancel command

These additional inputs would be optional and default to invalid refnums, which would mean "do not use the feature".

LabVIEW contains a mechanism for storing custom metadata of any type inside of VI files as "tags" (e.g. the path of an Express Source VI's associated config dialog VI) but the methods for manipulating them are marked as private. I think this could be a useful thing to have as an officially-supported feature.