It seems that if you have a VI (or function) inside of a disabled frame of a Diagram Disable Structure or Conditional Disable Structure then the Find and Find All Instances features in LabVIEW will not report them. I'm OK if this is the default behavior, but maybe the Find dialog should have an option/checkbox to search inside of Disabled Structures.
Note: This is really important for cross-platform and embedded target development where there's lots of use of Disabled Structures.
I wanted to use a property node in an application today. I happened to have the Help context up and it showed "Run-Time Engine: No". But I could easily have missed that and not discovered the issue until much later, after building a lot of code and wasting time.
If the node had an obvious indication as soon as you put it on the block diagram - for example, a different color - that would help a lot and potentially save a lot of headache.
At the moment, if I want to review my search results, I'm required to double click each item. This opens the diagram (usually) and the front panel. I then have to close them, or I might end up with dozens of open windows.
Of course I could use CTRL+G, but I'd still need to clean up the opened windows.
Another slowdown is that the highlighted item can popup anywhere on my screen(s). This "gaze time" adds up if you need to browse through dozens of results.
It would save me tons of time if the search results window had a preview of the result:
The found item should be in the center, preferably highlighted in some way.
It would allow me to give the listbox key focus, and use up\down to browse through all items very quickly, without any need to clean up!
If I have a Control labelled '%s In', I would like to be able to right click on it and select Create Indicator, resulting in a terminal label of '%s Out'. Likewise, if I have an Indicator labelled '% Out', I would like to select Create Control and automatically label it '%s In'.
Simple enough, but one of those tiny little tweaks that would save me a tiny fraction of effort every time I do it 🙂
I find the process of initializing Maps in LabVIEW to be unintuitive and inconsistent with the initialization process for other similar concepts (such as, say, arrays). After some initial trial and error, the process I've settled into for creating maps is to drop a map constant, and then to drag and drop the appropriate data types onto it for my key and value. I first looked for an Initialize Map VI (which doesn't exist) and then tried to create the constant by wiring up appropriate types to an "Insert Into Map" and creating the constant from there -- but this doesn't work as expected because the terminals don't update appropriately.
What drove me to coming to the forum today though, was that in creating a malleable VI with a map inside of it, I found a breaking point for the "drop constant and drag values into it" approach. Since the map data types need to be dynamic to support malleable VIs, I've had to get creative to get around that...
Sometimes, you may want to delete files that are read-only. The Delete primitive outputs an error (Error 😎 when you try to delete a File that's set to read-only. One then has to change the file permissions to writable and retry deleting it. That's a pain. What's even more painful is when you try to delete a folder, recursively, with the Delete function -- passing it a folder path and setting Recursive to TRUE. In this case, if even a single file inside the folder is set to read-only, then the recursive delete will fail -- now, the developer has to do their own recursion to find the file that's read-only, mark it as writeable and then delete it. OK, convinced this is a pain? Here's the solution...
Add an input called "Ignore Read-Only" to the "Delete" function that will do all this form me.
The OpenG Delete Recursive VI (in the OpenG File Library) has such a feature already. I was excited when LabVIEW implemented a recursive delete and I started using it all over the place (it's nice to write code that doesn't depend on external libraries, when possible) and then... I got bit by this limitation in some random corner cases where files had gotten marked as read-only.
Whoa there pardner, not so fast. The control reference labeled "Numeric 1" is actually linked to the "Numeric 3" control. And the property node labeled "Numeric 2" is actually linked to the "Numeric 1" control. Etc., etc.
I see no reason to change the labels of Control References and Implicit Property/Invoke Nodes. If you need to document them beyond their label, attach a free label to them. We don't allow changing the labels of subVIs, so the precedent has been set. For the sake of diagram readability, we shouldn't allow changing labels of these objects either.
Given the properties dialog box isn't resizable, and there's nothing under the table (apart from one tick box), could you make the items table longer? It's really annoying when there are a few extra values that can't be seen because the table is too small.
I wanted to suggest if it would be possible to add an option to resize the "Browse for Variable" screen which would help with the development of the new project. Especially when you have a generic subVI where you just change the variable but keep the logic built.
This idea was posted years ago and declined for lack of interest (it got 6 out of 7 necessary, but I would have been the 7th!). I would like to bring it back, I would like my application to have access to it's own version number. In fact you can open the project programatically and see some build properties but not that one. I can then grab the version from the build properties and set the default values on my FPGA code before compiling.
I was trying to make a pre-build VI that would look at the build properties and copy the version data into a control. Can't be done. I find this very useful to make sure that my RT system and my FPGA code have the correct versions.
Same as with an about box, or version checking for compatibility.
The previous thread suggested a routine in the FileVersion.llb but that seems to only be available in a single platform. Not useful for RT linux or Mac. The version is not available until the executable is built which does not work for FPGA.
At the moment my only recourse is to hand copy the version from the build properties and then set those as a series of 4 integers on the FP. (Then select them all and set their values to default, hence the other suggestion about right click)
On bigger projects, when creating a new class, I find it time-consuming to track down the parent class I'd like to inherit from.
It'd save me some pain if there was some kind of filter and/or search option for this on the New Class GUI:
Other thoughts on this:
- While the tree structure is useful, I usually know the name of the parent class I want to inherit from, but I don't necessarily know the full inheritance of it, meaning the tree structure isn't the most efficient way to find it. (Even alphabetical by class name would be faster in these cases).
- I'd find the tree structure here easier to follow if the lines were visible.
Since LabVIEW 2017, it's possible to build application with a compatibility with future version of run time engine.
This option is set by default but can be disabled.
I just discover that this option is set for real time applicaiton and cannot be unset. I mean that if you build your application in with labview real time 2017, it will run with a system installed with a newer version of LabVIEW Real time.
This can be a good idea, but I'm a little bit surprise that I cannot have informations on that options for real time application and I can't control it.
Here is a way to test it. Tested on a real time desktop with pharlaps.
Install RT target with LV 2017.
Build an application and set it to run as startup. A simple application writting something in the console is enough.
Make sure your applicaiton is running at startup.
Update your system by only installing LabVIEW real time 2019.
Restart your system and your application is still running !
Because I faced an issue where LabVIEW 2020 broke my application build in LabVIEW 2017, I'm asking myself how NI can garanty that a real time system will work in any case if we upgrade the system to a higher version of LabVIEW real time version without recompiling the application.
Real time system can be used to control system that can be a secure system. If a user update by error a system, I want to keep my system safe for user.
So my idea is to remove this option or give access to the user to unselect this option to avoid any bad behavior.