Working with class method VIs becomes easily confusing if you need to use VIs from several classes that are inherited from each other. Every class adds or overwrites VIs from one of the ancestor classes but usually you don't know which one. And if you're just user and not developer of this class structure you're usually also not interested in the exact inheritance hierarchy.
Look at the picture: As programmer of the application "main.vi" I'm just interested in Class 3 but I also need to know the internals of Class 1 and Class 2 whereby Class 1 is not even in my project. So I can't see that there are also other cool methods within Class 1 and to get methods from Class 2 I also have to search inside of it and compare against Class 3.
As reference: This is the content of Class 1
What I suggest and expect is the following:
=> The class tree shows all available methods within each single class!
bright colors: Methods that are defined in this class; pale colors: inherited methods
The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.
I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.
If I am on Mac or Linux and I try to open a VI that calls a DLL inside of a Disabled Structure, then LabVIEW searches for the missing DLL.
This is really a waste of time and effort, since it will never find or be able to load the DLL on Mac.
LabVEIW should be smart enough to know that it's not going to file a *.dll (Windows dynamic linked library) or a *.so (Linux shared object) on a Mac -- Mac uses .framework as it's shared library files.
So, I would extend this a little further and say that LabVIEW should only search for shared libraries of the type for that platform (.framework on Mac, .dll on Windows, .so on Linux).
Note: if a Call Library Function is configured for cross-platform (meaning it's configured for with a "*" file extension like mylibrary.* so that it will find the correct extension on the target platform) then go ahead and search for it.
In some cases the list of context menu items extends beyond the vertical screen height (for example when creating a property for a control). The only way to scroll up or down this list using the mouse is by hovering over the small arrows at the top and bottom (and quickly moving the mouse away to stop scrolling).
This idea is to enable mouse wheel scrolling on context menus where the list of items is scrollable (the scroll arrows are visible) and the mouse pointer is hovering over the list. This allows for precise scrolling with much fewer mouse movements.
When creating a new Source Distribution to run on an RT system. It makes no sense that the "Exclude vi.lib VIs" option is checked by default. The VI will not run and cannot be launched asynchronously which is the whole point of a source distribution on an RT system.
The "New Source Distribution" wizard that creates it with default properties should look at the context it is being created and pick appropriate options. This is supposed to be a smart IDE.
There is a path type selector (Valid Path/Not a Path) on all the path controls. This is useful on "data" type controls (subVIs) where you may wish to test input values, but rarely useful (may even be confusing) on path controls used on end-user facing front panels. They make no sense at all on indicators. These selectors are most prominent on the NXG style controls:
Here's an idea to be able to hide these buttons, just like we can hide the browse button. Perhaps Show/Hide/Hide at runtime options, but at least Show/Hide options.
The idea is the same as Separate Compiled Code From Source File. When using external source code control (SCC) software like git, the user may want to track only the source code content changes. However, when every time saving the VI, the VI Revision History will be incremented. This reflects the change in VI attribute / VI properties, even though the other contents are the same.
This makes the commit log like git hard to trace the real change in the source code content from a high level. When using the compare VI tool, this attribute change will be one of the highlighted difference, which is quite distracting & confusing such as below:
I suggest this option can be disabled at the level of VI, project, or environment like the option of Seperate Compiled Code from VI. Hope it would be accepted 🙂
LabVIEW currently allows users to execute a MATLAB script inside the "MATLAB Script" structure, which lets you add inputs/outputs to the edge, set datatypes, and then type your MATLAB code in the central box.
If you already have a MATLAB script, you can use the right-click menu to "Import" (and conversely, you can test a script in LabVIEW and then Export it, if you wanted).
However, you cannot link to a script by path. Importing simply copy-pastes the content into the Script node. This behaviour, whilst probably useful in some cases (avoid future changes to the .m file breaking your nicely tested LabVIEW code) is different to most other nodes I can think of (Call Library Function Node, Python Node, .NET methods, ...).
Please add an option to pass a path to a "myFunction.m" file to the MATLAB execution system rather than copying the contents of a .m file into the structure's box.
(As a workaround, I believe this could be accomplished by running the MATLAB interpreter via command line and using the System Exec node, but that would require various path -> command line string parsing operations, and perhaps complicate cleanup of VIs using MATLAB.)
I know that many extract wires 'upwards' and later on merge errors to collect errors and continue. From a layout perspective it's natural to add the top code to the top input of Merge Errors, but from a data flow perspective any error that happens there is often secondary to the 'base/lower' part of the code. This means you need to connect the top code to the bottom input of Merge Errors.
Wouldn't it be nifty if you could have an r-click option or input of "reverse order" or "merge from bottom"?
I assume that it behinds the scenes makes an array of errors and looks for the 1st one, so this would only add a 'reverse array' inside the function. To not have that ability forces you to do a Build array, Reverse array and Merge Error, which feels unnecessary.
Since development of Labview NXG will be discontinued this year, a back conversion tool would be extremely helpful in order to move NXG-projects back to the original Labview. I think NI has the responsibility to help the programmers who followed their call to the "new and future version of Labview" which is now discontinued.