Closing the front panel (FP) of a VI also closes its diagram. But, in opposite, the FP remains open when the diagram is closed.
Sometimes it would be very useful to simultaneously close the FP of a VI when closing its diagram.
This would avoid to either switch to the FP (Ctrl+E) to close both windows from it or the need to close the FP separately.
Could this be implemented by the Ctrl+Shift+W keyboard shortcut and a Shift+Left click on the close button of the diagram window ?
If we have a horizontal axes (x-axis) scroll bar, why not a vertical one (y-axis)?
When doing plots for geological logs the vertical axis is used as a depth scale and users always scroll in a vertical direction. I had to improvise this in LabVIEW and it took alot of code to handle the rapid successions of scroll bar change events that get generated if a user uses the generic labview scroll bar to scroll a chart.
Why don't I have the option to add row headers to a single column listbox? I can add a column header - and there is only one column. It is often very helpful to show the row number in a listbox and there is no easy/good way to do this for a single column listbox
Most of the new LabVIEW users will start programming from the scratch. They really find very hard to understand from where did this particular object (function) came from. So if the location of it is displayed in the context help it will give a better way to easily find that object from the location.
Ex: "Create User Event" can be displayed in context help as below
Location: Programming->Dialog&User Interface->Events->
(or in a shorter form that everybody understands).
Sorry if this idea has been discussed before. Or its not at all needed. For a newbie this will help definitely.
Inconsistency is found in the supported image types for many IMAQ vi's:
For instance IMAQ ROIProfile, IMAQ LineProfile and IMAQ LinearAverages supports U8, I16 and SGL format but do not support U16 format images.
But, a profile along a line drawn in a U16 image should make as much sense as in an U8 image. Shouldn't it? So why is it not supported?
In addition, I would expect it to be easy to add an additional polymorphic U16 version.
These are just a few of several examples of similar inconsistency in IMAQ vi's.
Most of applications we write in LV are contained inside of a project. Saving it to disk creates a lot of files (.lvproj, .vi, .ctl, .aliases, etc) and subdirectories. This is convenient when you want to copy one VI or control to another project, but very inconvenient when sending this project to someone. In this case you have to create an archive to put everything together. Make an option to save all items contained in a project in one file.
Making a Windows Explorer plugin to automatically open such files as directories would be also a nice addition in this case.
Suggestion for developers of LabVIEW Web UI:
We would like our Web UI to have a very similar look-and-feel to the core application it is tied to. To facilitate that, it would be useful to be able, in WebUI, to be able to point at a VI and say "import panel" - the tool would then import all sensible importable features of the VI's front panel, as a starting point.
Presently i use the below mentioned snippet for calling a SubVI (with UI) for it to be a part of the Main VI (like an excel sheet) so that i dont see multiple windows in the desktop tool bar.
"Creates a Child VI into the Front Panel of the parent vi. Child and parent vi must already be loaded into memory.
Created by: Jack Hamilton
The idea here is to include a option the VI Properties to add this option something like this
The numeric controls can be configured by specifying Min/max values ... and behaviour when going over these limits (Coerce, ignore ... )
This feature works fine on the front panels ...
But when you modify the value of such controls programaticaly using a property node ... these constraints are not taken in account.
It would be nice to apply the MIN/Max limits also to the "value property" (and valus signaling too)
I am not sure whether something similar has been propoesed or not..
This is something to do with the ICON EDITOR...I propose a "ICON Manager" (see Endevo ICON Manager) with which it should be possible to apply the icon to all the vi's/ctl present in the directory or llb.
-->The Name of the folder or the first name of the vi (ex: If the subvi name is "abc_xyz.vi", then "abc" will be the header and "xyz" would be the body) can be used as the header. (or automatically find the header)
-->An option to preview and apply the same to all the vi in the directory (whether they are linked to one another or called dynamically should not matter)
-->An option to select the Main (toplevel) vi and apply the icons to all the calles
At my current work place we use proxy servers as an internet connection. With LabVIEW it makes it difficult not only while the NI software is being installed (to check for updates, connect with server for veryfication etc) but also during typical work it makes troubles with finding examples and drivers from a development enviroment.
I would suggest adding some advenced internet connection options for proxy settings etc.
Another little thing with a company computers is that, even when installing NI software on a D drive it still installs some example software on C:. It makes problem when your IT limited your C drive for absolute minimum, because with huge amount of NI software the amound of "additional" data is getting bigger and bigger.
We already have inline VIs that are compiled directly into the code, just as if you had wired the code on your diagram. Imagine if we could designate some of the inputs and outputs as polymorphic. We could create VIs that do simple math operations, comparisons and other stuff without having to create a dozen versions for the different inputs and outputs possible.
I think the outputs would have to be either a fixed type or same as a selected input. Some inputs, such as strings, wouldn't work in many cases. If the input wired to the inline VI was not compatible, it would just fail to compile and give you a broken wire, just as if you had wired the same code into your diagram. It really would just be a block of code that could easily be added to a diagram as a VI, but it would be recompiled based on the inputs.
LabVIEW opens the file in the version of LabVIEW that was most recently opened instead of the version the file was saved in. Add a header to the file to allow LabVIEW to open the file in the correct version. This will save a lot of time and lower frustration of accidently saving a file in the newer version.
The Report Generation Toolkit does not allow you to delete a worksheet (or anything as far as I can tell). I realize that it is a "generation" toolkit, but it does have modification functions such as being able to overwrite a cell. Deletion is a modification function of sorts and it seems like it is a pretty basic function. Also, figuring out how to open an existing file is not obvious. You have to use the New Report function. It turns out that you can use an existing file as the "template", but that doesn't show up in the documentation. Rename the function as New/Open, something similiar to the file I/O Open/Create functions and at least add a note to the help file.
"Make & keep your wiring diagrams neat" is something that has been preached to me since I built my first VI.
One thing I think that would go a long way to help with this would be to be able to lock the wires on the block diagram to it's grid. This would keep wires equidistant from each other and give the block diagram a much neater look. This would probably mean that, if this option were enabled, the "Alignment Grid" pixel size would need to be locked, Also included would be something that would prohibit one wire from laying on top of a parallel wire.
These two would help to sort out VIs when you want to make llb plugins, to determine who goes where.
I'd like to right click on an item in the project explorer, and have two more options "Open private callees" and "Open public callees.
By "private callees" I mean: the callees that the selected VI is the only one to call in the whole project.
By "public callees" I mean: the callees of the selected VI that are called by at least one other VI in the project.
(I mean directly called and not dynamically of course, the developper would have of way to distinguish his VIs that are called dynymically).
Again, I've done it for personal purposes, here's the snippet in 8.6 for those who might like it.
There are times that I wanted to use a numeric constant or control as a string data type. In order to use a different data type, I would manually copy and paste the control/constant values to another data type. Moreover, if the control or constant is an array of values, it's tiring to do a manual copy of the values. Creating a vi that would convert the data type would also take time. As a suggestion, I hope LabVIEW can include in their "right-click" property box a method of converting the Path to String, String to Path, String to Numeric and Numeric to String.
I don't know if this is a big thing or not. Just a piece of thought.