Even if you don't (yet) work with LV classes, you may have noticed that they are starting to become increasingly widespread in the LV world. In fact, the excellent new Actor Framework that ships with LV2012 relies heavily on classes. LV classes are great but they can impact on your performance as a developer as your application becomes larger. I'd encourage everyone to click the magic KUDOS button for this idea, since classes will likely affect us all sooner or later!
The problem:
Most class-based architectures contain some degree of linking. One form of linking is inheritance where parent-child relationships are implicitly defined, and another form of linking arises from nesting libraries where classes (e.g.) are placed inside other libraries.
Unfortunately as the linking increases in a project, the IDE starts to become very sluggish! Those who have worked on mid-sized class-based applications know the symptoms:
Opening the "class properties" window takes 10 seconds or more
Renaming a class brings the editor to a standstill
For many projects these symptoms are a minor annoyance, but as your project grows they can become a serious impediment to productivity. Why should it take over 30 seconds to modify a class's inheritance?!
Obviously careful design can reduce linking to some extent, but that just postpones the pain. The reality is that all class-based projects start to suffer from these symptoms once they reach a "resonable" size.
The idea:
Improve the responsiveness of the LV editor when working with classes.
Highly repetitive tasks such as editing a class library's icon deserve a snappy response from the IDE, regardless of how many classes I have loaded!
Modifying inheritance is a fundamental operation. It should be quick and easy! (See this related idea)
Placing classes in libraries promotes good project organisation. It should *not* bring the editor to a grinding halt!
Credits:
Others have written about this topic well before me. Here are a few relevant discussions:
Pressing Shift and dragging an object with the mouse make it move only horizontally or vertically. Great!
Unfortunately Labview decides which direction to move (horizontally or vertically) based on the first pixel the mouse moves. So, if you want to move something horizontally, but while clicking your mouse moves one pixel vertically, you're stuck with that direction and can start over again. ☹️
"Normal" applications decide the direction to move based on the ratio of x/y mouse movement: If the mouse moved more in vertical direction, the user obviously wants to move that way, if the mouse moved more in horizontal direction, then that is the user's intent. This means you can switch the direction while dragging and you're not stuck to one direction!
PLEASE modify the annoying behavior of Labview accordingly!
I´m not to fond of the native Boolean constants and their ability to change value by just a mouse click. To me that is not a behaviour of a constant. What if Pi could be changed to e with a mouse click?
The issue is that when clicking around and cleaning up a messy diagram you may by mistake change a Boolean constant without noticing.
I would like to have native immutable Boolean constants like the ones I´ve implemented with two small VIs. My artwork is perhaps not the best, better ideas are up for anyone´s suggestion.
It's a little annoying to try to draw long wires to a terminal that's currently off screen -- you have to hold your mouse at the edge of the screen and LabVIEW slowly scrolls the window (Shift will speed this up a little bit). Currently, neither the mouse wheel nor the touch pad work for panning/scrolling while a wire is currently in progress.
As an improvement, it would be great if the mouse wheel allowed panning the diagram while the new wire was still in progress.
When looking for unexpected behaviour in time or memory usage of a project the Profiler is useful and easier than the execution tracer, but it could be made much more useful by adding the ability to monitor for changes and analyse the issues.
Issue: Currently detecting how the memory or run counts e.g. of a VI changes over time you have to take snapshots, save them and then compare the values in e.g. Excel. (which the saved traces do not directly fit into either...)
Proposed feature: Trends It would be nice if you could just set the tool to automatically sample and log all/selected numbers regularly and then be able to view the trends.
Proposed feature: Automated Analysis Having trends will help in manually detecting issues, but the profiler could also have tools that helped you in this, e.g. highlighting which VIs show a continous growth in memory. This could also then be expanded by being able to call a VI analyzer on any given VI - preferably made/set up to identify possible reasons for a memory leak e.g. (unclosed references, continous array building e.g.).
I would like to have the ability to make a Front Panel background transparent without making the whole window transparent (where the later is currently possible through property nodes). This one item would expand the UI possibilities. It would allow for the creation of Front Panels that seem to be borderless similar to many splash screens, about screens, and gadgets. Below are some industry examples:
Adobe Splash Screen (No border, has shadow, not square)
Microsoft Word 2010 Splash Screen (No border, rounded corners)
Resource Meter Windows Gadget (No border, specialized graphic)
Windows Media Center Gadget (Empty-transparent space between two UI elements)
Right now if you have a string constant in a VI and you edit it and save it, LVCompare just highlights that the string constant has been edited. For small strings, not a big deal. However I have a bunch of big long SQL query strings. In that case LVCompare is pretty useless. I know I changed the string constant, what I want to know is what did I change in the string constant.
I currently have a project with an auto-populating folder for documentation. That documentation is included in my Installer build specification.
If I regenerate that documentation while the project is open, the auto-populating folder sees it disappear from disk and removes it from my installer! No notification, nothing. Just completely silent. This has resulted in shipped installers with missing documentation
I propose this should work the same way any other dependency does if it disappears from disk. It should break the installer from building and show a warning sign that the dependency is missing.
Let's Encrypt is an Certificate Authority (CA) that provides FREE TLS certificates for people and organisations to secure their websites and servers. Their certificates are valid for a maximum of 3 months, but client applications can automatically update the certificate when due.
It would be very nice to have this functionality in the NI web server. Exipiring certificates are cumbersome to manage.
The IDE would be more consistent if all the toggle-able features were collected together under the "Visible Items" submenu. Photoshopped example of a FOR loop below, but I'm sure there are others. "Show Dynamic Event Terminals" comes to mind...
As shown in below image we can see that, if I index numeric array and wire it with any of the node from numeric function it gives un-aligned wire whereas as same process if I use Boolean function at output of index it gives well aligned wire.
So due to this numeric function node wire to index out terminal makes our code with full of wire bends which is not as per NI LabVIEW coding standards also.
So here, I want to draw attention for NI, to do some correction to specific numeric function nodes so we can make neat and clean code in LabVIEW.
This is a very small suggestion, and hopefully easy to implement. When wires cross, very often one of the wires involved is an Error wire, and as it is usually wired last, it sits on top of all the other wires. All I'm asking is that Error wires are always placed underneath all other wires when they are created. To my mind, this improves the readability of the diagram.
What would help further is if Error wires were "faded", as if they were 50% transparent. You do need to be able to see them, but not such that they stand out. But I'm much less certain that such a change could happen. The khaki color is an improvement on the old pink though, that's for sure!
In LabVIEW project file XML some information are generated by LabVIEW. For example:
Dependencies
PersistantID
FPGA stuff
...
These information should not be commited to source code control system and having them within the LabVIEW project file makes it very painful to maintain a clean GIT history.
It could be very convenient to store these information into a separated file with a specific file extension so that we can easily ignore with .gitignore file.
The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.
At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".
One such example is the file naming convention:
Using spaces for separating words.
Using Libraries to namespace VIs instead of including the noun in every related VI.
These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.
I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?
If there is not, then I think could we collect some ideas here for updating this document.
At least not at first. The compiler could inline each prototype and when called repetitively, use normal recursion. But that would be next level, and maybe not even desirable.
The scalar string input is simply not a stable input for this malleable VI. It will always result in infinite recursive compiled code. So, this should break the caller.
Of course, it should be perfectly legal to have a disabled type specialization case that calls the same prototype. As long as it's not actually compiled, that's perfectly valid:
In LabVIEW IDE, when configuring executable build specifications, under "Version Informtion", it could be greate to have a string control to store free information depending on our version numering management (ex: alpha, beta, release candidate ...). This value could be used as a postfix to the 4 digits version (ex: version "1.3.0.1 alpha 5").
In "Details" tab of Microsoft Windows executable files, the "Product version" metadata is a string so there should be no problem.
If we type up a list in a text label we can now (since LabVIEW 2023) right-click on it, select quick change and convert it to a number of different objects (array, enum, boolean etc)...Once you have done however, right-clicking on the result does not offer the quick change option anymore.
It would be nice and feel more consistent if the same option was available when right-clicking on the supported objects as well; allowing us to convert those to any of the other options and/or even back to the original list (which would allow you to then edit that list efficiently and then reconvert it). Basically an label/object to object/label quick change, instead of just label to object.
PS. I know there are various quick drop plugins that do parts of this, but this would extend the now in-built function to cover those and more scenarios...
