LabVIEW Idea Exchange

Since the Error Ring constant is read from  *--errors.txt files at LV startup and then ignored it is cubersome to add new error codes "while coding", you have to restart LV to get a refresh.

Please give us an option to re-read the contents of the errors.txt files from within LV, maybe from within the Error Ring popup dialog.

/LeifS

It could be useful to have the possibility to set the Runtime Menu of a control by specify the .rtm file

Dany

We currently have an API to edit it

What I propose is to extend it with a couple of new function:

Open/Create Menu File : Open/Create Menu File return reference to the menu.

Write Menu File: From a reference save the file to disk

Close Menu File: Close the reference to the menu file

Dany

Many versions ago, we got the "static VI reference", and it made our life easier. I am suggestion a similar "static control reference" that can be tied to e.g. a strict type definition *.ctl file so we can read certain properties.

I have several type definitions that are exclusively used as diagram constants. Since there is no control in sight, I cannot use a direct property node. It would be a shame to have to place a hidden instance on the front panel just to get to the properties.

Well, we can use a static VI reference to point to the *.ctl file and start peeling until I get to the actual control (top image). However, it would be nicer if the static control reference would directly give us access to the properties of the control, such as the strings of a strictly typed enum in my case here.

With my suggestion implemented, the same code could be done as shown (bottom image)

The current way to get a static reference to a *.ctl file via a static VI reference (as described above) should be retained, because sometimes we need access to other properties.

I am suggesting a new dedicated "static control reference" that would give direct access to the properties of the actual control in the *.ctl file.

(of course some properties (e.g. value) would not make a lot of sense if used this way. Maybe there is a much eaier way, but I haven't found it).

It would really help to be able to catch an "Region of Interest change" event on an image display control!

And of course the ability to discard it from within the event structure.

Thanks in advance!

When developing, debugging, and optimizing code, I see myself constantly switching between debugging enabled and disabled. Most of my polished VIs have debugging disabled, but when developing a new project, I would like it enabled initially, e.g. to place a probe or use execution highlighting. This switching is currently tedious (VI properties...execution...allow debugging).

I would prefer if this configuration would be moved out of the "VI properties" and directly to the toolbar.

It could be implemented as a collapsible menu, similar to e.g. the current search bar. I assume that the switch involves a recompilation, but I've never seen any noticeable delay when switching between modes so I think it would be OK. (Of course switching over should not be possible when the VI is running.)

It is also less confusing to the new programmer who might receive a VI that has debugging disabled. Currently it might not be obvious why certain buttons are missing.

Here's a very rough draft how it could look like:

Installer needs option to conditionally install files.
In some installs, like a new install, the installer should install a file but that same file should not be overwriten on an update. For example, a database file that is updated by the user will be overwriten by the installer.
The options required are:

• Install file if not present.
• Install file or not install if file is modified. 

InstallShield should be consulted for the various options required.

The windows uninstall control panel is typically very bloated with tons of entries. A good solution is offerend for NI software where a single control panel entry allows access to all NI software products, from development system, to drivers and run time engines.

(I am sure there is a proper technical term for it, but I don't know how one would call that mechanism)

I would love to do something similar for all my software installers, such that they would all install under a single entry (e.g. "Altenbach Software" ;)) and double-clicking the entry would open a software manager for all my program that would allow repairing and uninstalling any listed component.

Enough complicated descriptions: It should work exactly as the NI entry.

IDEA: When building an installer, we would simply specify an "installer group" or similar for each program and the rest will fall into place.