Formula Node output variable names should be shifted right 1 pixel within their borders. Currently, the names are left-justified. Since each character is also left-justified (i.e. the white-space to separate them from adjacent text is on the right of each), input variable names have a 0-pixel left margin and 3-pixel right margin within their 1-pixel border. Since the output variable two-pixel borders grow inward to match the outer dimensions of input variables, the text pixel is cropped with excess on the right. This is problematic for the 1-pixel wide lower-case letter L which is cropped in half by the left border but still has a 2-pixel right margin. If shifted, names would be centered, cropping would not be as apparent, and the letter L would be distinct. The image below is enlarged 200% so the issue is more obvious (but the name is easier to read).
Currently, to allow a user to select a relative path within a Path control, you must either:
1. Easy (but glitchy) method:
- Catch the value change event on the Path control;
- Compare the NewVal with your base path with "Compare Two Paths.vi";
- In case the path is relative to your base path, rewrite the relative path to the control using a local variable;
-> This results in a visual glitch because the value is updated twice.
2. Recommended (but complicated and not very clean) method:
- Take a first Path control, move the "path box" out of view, but keep its browse button visible;
- Put a secondary Path control next to it, with its own browse button invisible;
- Similar to method 1: catch event on first path, update secondary path;
-> No visual glitch, but difficult to adapt to paths inside arrays, clusters and combinations of both.
For both methods, additional logic may be needed in case the user is typing in the path box directly.
So the idea would be to add a "Base Path" property to the Path control, so that when the user clicks the browse button and selects a path that is relative to that base path, the control would get the relative path value instead of the absolute one.
In case the selected path is not relative to that base path, the control would still have the normal behaviour and get the absolute path value.
By default, this property would be set to "Not A Path" (or empty path) to keep the current behaviour.
Also, it would be the developer's duty to correctly treat relative path values and inform the user to what base path it is relative to.
I spent a good chunk of time yesterday trying to find out why I was getting a Wires Under Objects VI Analyzer failure, and after much paring down of code and fiddling with wires it turned out to be a hidden event data node that was running over a wire. Below is a simple reproducing example; the second image is identical to the first, except that the event node has been hidden (but not moved). Both of the images below fail the Wires Under Objects test, and my argument is that the one on the right should not fail that test.
Event node visibleEvent node hidden
The point of the feature "hide the event data node" is so that I, as a LabVIEW developer, no longer have to worry about it cluttering my block diagram and it running into/over other items. However, hiding it ultimately results in me still worrying about where it is hidden because it running into/over other items still turns out to matter when I run static code analysis. From this POV, this is a bug, and the VI analyzer test shouldn't fail.
This POV is also consistent with the way that hiding for/while loop iteration terminals operates. In the images below (again, the second image is identical to the first, where the iteration terminal has been hidden but not moved), ONLY the left image fails the same VI Analyzer test, and this is the behavior I'd like to see with the hidden event node:
In case of a front panel with several buttons, a dialog to set the Key Navigation option for all of them would be more convenient and faster than having to open the properties of each button individually.
I use Error Rings for custom errors and I love it. Being able to reuse existing codes but give addition information, or using extra string or numeric inputs makes my code more compact and readable. But one thing I noticed is that if I perform a search in LabVIEW, it won't look at the text in the Error Ring. Here is an example.
Even though my Error Ring contains the text "table" and it is even shown in the node, the LabVIEW search returns nothing. There are times that my users get an error and they send it to me. Then I will search for that text in my project only to find it isn't there. But it is actually there, just hidden away inside the XNode that is the Error Ring.
Can we improve the LabVIEW search function to search inside Error Rings?
When we use diff to compare old and new VIs, currently both the FP and BD open and the FP is on top. But frequently the FP hasn't changed at all -- the API can stay the same while making substantive changes internally. So in cases where there is no FP diff, please put the diagram window in front. That would make reviews of large quantity of small changes (like replacing a commonly used subVI with a new subVI) easier to quickly review.
If I drop down a color picker control, I can get an event on it for when a new color is selected by using the value change event. But what if I want to know what color the user has their mouse over, before clicking on it? Many of NI's controls change color as you select a new color. The Graph plots for instance will update as you move the mouse around.
This idea is to allow color picking controls to have a new user event, which is Mouse Over Color which gets generated when the user mouses over a new color. This way we can make applications that change the color of some UI element before the user picks the new color like NI does.
This can be accomplished today by recreating the color picking functionality in a new VI. Here is one example posted that allows you to pick a color. Using this someone could generate a User Event, or post to a global as the new color selection is being made.
It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.
It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.
I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.
When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.
This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.
This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.
A malleable VI on a block diagram can be converted from an Instance VI to a Standard VI, which I've found useful to aid debugging. Unfortunately this modifies the calling code and requires the changes to be reverted to restore the original malleable VI.
This idea is to provide an additional right-click option for malleable VIs - View Instance VI. This would open the instance VI in memory, and allow read-only viewing of the block diagram.
This is useful when examining how the Type Specialization Structure cases are being evaluated given the currently wired inputs to a malleable VI. It also offers ability to quickly view the instance VI data types, helping determine which malleable input wires are *actually* broken. In the example below LabVIEW shows all of the inputs to Stall Data Flow.vim as broken, though viewing the instance VI shows only one input is actually broken.
When the Instance VI is opened for viewing, it wouldn't offer any runtime debugging, but means no changes need to be made to the calling VI when performing static code analysis at edit time.
The ability to view instance VIs already exists in LabVIEW through VI scripting (see example below), but would be nicer to have quick access to it when right-clicking a malleable VI.
Currently, the Third-Party Licensing and Activation Toolkit doesn't handle PPLs. This makes creating a plugin, pay-per-component architecture difficult. Handling licensing and activation of PPLs is needed as part of TPLAT or some other mechanism.
Lately I used Visual Studio Code to edit Mark down files and other text files. One feature that I use is the GIT integration to VS Code. For text files the diff is integrated to VS Code and it's very useful to take decision on which files to commit or not.
It could be nice to have the same type of plugin into VS Code to diff LabVIEW VIs.
I think LabVIEW should have something like the dialog VIs that acts as a popup where the vi displays a message to the user but doesn't hang up code and wait on the user to press a button.
An example case is a state machine that has error checking built in errors out. Instead of creating a more complex error handling scheme to display the state machine errored out and heres why then shutdown the state machine, you could instead drop this async popup in the state with the message to display the error occurred then have the state machine shutdown like normal. This way, the user knows "the state machine shutdown for X reason" while the state machine also goes into a safe state.
I think the async popup is easier to trace since the error message is located in that section that detected the error vs having some sort of store an error string then in the shut down case read if there is an error and if so display the error once the station is already shutdown. Additionally, you cold see where all asnyc message blocks are via dropping one in your code then right clicking and searching for all instances. This could streamline the process to see where the fault occurred since the async message block would be in the location of the fault itself.
I have currently built something like this that is a reentrant VI whose input is a string and a secondary VI that launches the display message VI. It's a bit of a work around, but I can display a message to the user while my code continues to do whatever it needs to.
LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project:
Great! Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.
However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.
The request: Add the ability to either open or abort these running VIs from this window. It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:
(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)