LabVIEW Idea Exchange

You cannot currently install MAX as a standalone product- you need to install it along with something else. I need MAX on basically all computers I build my installers for, so I always go into the Additional Installers menu on the Application Builder, then pick (usually) "DAQmx with Configuration Support". Unfortunately, this also means I have to uncheck "Automatically select additional installers" so I can go find the "Configuration Support" item.

I almost always want to let the App Builder pick my additional installers for me, so I will check "Automatically select", then uncheck it, then go check the box for "...with Configuration Support" for one of the items that got automatically selected.

I'd like a box that lets me prefer the "With configuration support" version of whatever I'm building so I can make sure MAX gets installed. For my use, it doesn't seem to matter if I pick "DAQmx with config support", "VISA with config support", etc.

I'd ask to make MAX a standalone installer, but that would require me to uncheck the "automatic" box to add MAX to the list, which doesn't really help. I just want to say "Hey Appbuilder, figure out whatever you need, and ALSO install MAX."

Pro-grade mockup shown below:

I would like the option to connect a control/indicator, such as a Graph, Table and Arrays, to a matching typed DVR reference. 
This would allow the developers to work on large datasets in-place and the connected indicator would reflect that change with out having to pass, essentially, a large copy of the data to the control/indicator. 

The speed and memory efficiency improvements could be huge for large datasets.

Similar ideas have already been posted but non of them totally hits what I'm missing.

As always - what is the current situation?:
- LabVIEW is installed under "C:\Program Files (x86)\..." - this is a folder where admin rights are usually required to modify it.

- in the named folder the standard VIs are included: vi.lib / user.lib / instr.lib

- my project lays somewhere else - e.g. "C:\myLVProjects\project1", "C:\myLVProjects\project2", ...

- my first project is LabVIEW32 bit, my second is LV64bit,
- one project needs to have the binary code separated from the VI, the other one not
- one projects needs some toolkits from the VI Package manager, the other one not or maybe even incompatible ones to the first project

- one project needs VIs from an additional search path, the other one too but with a different version

long story short:
There are many situations where the configurations of two or more projects conflict with each other. Therefore, switching between two projects can be quite effortful — from adjusting configurations to (de)installing toolkits.

What I like to propose is the following:
Having a new option in the LabVIEW start screen "Create a new development environment".
The only the user has to do is to select a folder on a drive with enough free space.
LabVIEW shall now setup an entire code- and configuration environment. Means it copies vi.lib, user.lib, instruments.lib to this folder. It create a LabVIEW.ini and a link to the exe using this INI. It creates a folder for the compiled object code cache and so on. Installing add-ons from VI package manager shall also be stored in this new folder structure.
And of course, there shall be a place where I can manually add some libraries, my project files and finally also my build results.
If LabVIEW is now started from the named link it only uses the VIs from the environment folder as long relative paths are used (which shall be default).

Again in short: I expect an encapsulated environment that contains everything that is needed to develop one project entirely independent from a second and third project.

Since a few years, we have native support for Map and Set in LabVIEW.

How about adding a DataFrame type similar to other programming languages (possible even with a native interaction with Python)?

A DataFrame type would be a 2D value where columns can have different datatypes. Currently, one needs to build around this by creating an 1D array of a cluster (or class) type.

Access to the data would be with numerical indexing for the rows and field access (like in a cluster) for the columns.

KR, Benjamin

It's hard to believe that this is the first post to request something like this (pun intended), but I couldn't find it after a few queries.

The base idea would be that both the static and dynamic connectors used to connect the methods to the owning class shall be defaulting to the owner class, a.k.a. this object in text based languages. The main problem is the use case for refactoring. When moving around methods the class controls and indicators have to be replaced every time. It doesn't matter if I'm moving methods between classes or to interfaces it is the same pain: replace the connectors (with QuickDrop), then change the names to class names, then update the icon, finally move the VI to the new location.

I know that this could and maybe is already solved with scripting, but I think the development environment shall grant the option to change the control and indicator to this object that will always default to the owning class, without manual updates. Even the labels could be This in and This out, and replaced in real time with the actual class implementation on the block diagram of the calling VIs.

The proposed solution would also get rid of the error telling about the dynamic dispatch controls shall reference the owning class, since it would happen automatically.

For everybody who deals with a lot of different LabVIEW versions it is difficult to handle the versions.

If you forget to select [save for previous], the code will be recompiled to the newest version.

There is a new feature to select the expected version in the project manager (started with LV2024). 

But there is no possibility to select a specific version for the development environment itself (eg in the menue [Tools] - [Options] - ...