When manually analysing a project, we can set the target in which the VIs should be loaded. Unfortunately, VIs with RT code are often broken under windows, leading to wrong test results, or even worse, pop-ups asking for VIs.
Please add an Application Reference Input for the VIAn Run.v.
Maybe this option could also be useful set in the VI Analyzer configuration file?
By default, overrides of interface methods with the default dynamic dispatch connector pane (object in/out and error in/out) look like this:
This means that the default override of interface methods do nothing EXCEPT DROP INCOMING ERRORS, which is bug territory imo. Ideally, they would be scripted to look something like this:
Yes, I know I probably can mess with the project provider to get this. No, I don't want to have to do that! 🙂
I have wasted days weeks of my life tracking down why dependencies are loaded in LabVIEW.
This is because the "Why is this item in Dependencies?" tool isn't particularly useful in larger projects. And it isn't particularly useful because it highlights any file in your project (and not in the dependencies) that is dependent (no matter how indirectly) on the chosen file.
In this example, if I click on "Why is this item in Dependencies?" on library C, I get pointed to a VI in the project (A.a) which has a very indirect dependency on library C.
It would be far more useful to me if I instead only got shown the VIs that directly depended on my dependency (even if they were in dependencies themselves). If I then wanted to follow this up the chain, I could just click on "Why is this item in Dependencies?" again, but on the found item.
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.).
For projects, libraries, and their associated files, if the "Save Version" property is set to an earlier version of LabVIEW, the project and its files are not recompiled to the editor version. There should be an option on the Mass Compile dialog that allows the "Save Version" property of projects, libraries, and classes to be overridden.
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:
Since most (if not all) controls and indicators can be moved around with "position" property node programatically, the X and Y coordinates on the front panel are useful information to have.
As of right now, users have to adjust the position values by trial and error to know what values suit the UI, or maybe make a program to capture the mouse position programatically.
So I've been getting feedbacks from customer about a function where one can view the coordinates of the mouse all of the time. (meaning no programming is necessary)
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.
(Note that this idea has already been proposed and auto-declined. So I'm trying again, this time with a different UX, and pictures!)
I've got some code on my diagram:
I need to wrap the code in a case structure, so I do:
Then I connect a Boolean wire to the selector terminal and go on my merry wiring way. Unfortunately, I forgot to consider the fact that I need this code to run in the FALSE case, not the TRUE case. But since nothing is broken in my code, I don't realize my mistake until I start running things. I've made this mistake so many times over the years (the most recent being tonight), that I've decided to propose a solution.
There are plenty of times that I want the wrapped code to be in the TRUE case. There are also plenty of times I want the wrapped code to be in the FALSE case. With no obvious default that makes sense most of the time, here's what I propose:
If you interactively drop a case structure by dragging a rectangle around *existing* code, we float a button over where you let go of the mouse and give you a chance to make the visible frame the FALSE case instead of the TRUE case:
(I suck at Microsoft Paint, I'm sure somebody can come up with a better looking button or glyph)
If you click that button, then the case structure turns to the FALSE case. If you do *anything else*, the button goes away and the case stays TRUE.
With this proposed change, any time I wrap existing diagram code with a case structure, I'll be forced to think about whether the case needs to be TRUE or FALSE. And I'm given an easy out if it's supposed to be the TRUE case.
Currently (in LabVIEW 2010), you can add labels to wires. Hurray!!
But it's painful. Boooo!
Curently => Right-Click wire, navigate to sub-menu of Show>>Label
It should be as easy as adding free text to block diagrams or front panels. For example: If your auto-tool is on then just double-click on freespace to add text.
So we should make it just as easy to add labels to wires:
Step 1: Single-Select Wire
Step 2: Start Typing
Step 3: Profits!
We don't need no stinkin' right-click menus.
PS: I am proposing a single click on the wire instead of double-click because that performs a different action.
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!
A portal view to the Front Panel elements from the Block Diagram through a feature like "View As Portal". This would be especially useful in the case of G codes doing calculations, simulations, and modelings in the Block Diagram for people like researchers, scientists, and educators.
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.
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.
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.
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 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...
