VIMs are awesome but when wire inputs are broken they aren't awesome. They'd be awesomer if there was a way to specify that when specific frames of type specialization structures are active, there is a way to get specific strings added to the error info for the caller. Having a way to add custom strings to VIMs would overcome the general "An unsupported data type is wired to this subVI node." error string we're currently given. This can also help differentiate between LabVIEW breaking during type prop for odd (bug) reasons and properly invalid inputs... Do I need to just delete a wire and re-wire the input or do I need to hope the developer provided good VI documentation?
With some additional frames in Type Specialization Structures and maybe something like a subdiagram label but instead it could be a error reporting field at the bottom of a frame, it would be much easier to provide meaningful information back to a developer such as "GUID input only accepts GUID.ctl or a String". Then if the caller breaks with the unsupported data type error for the VIM, error details from the currently active TSSs can be concatenated to the Details string displayed in the Error list dialog. Alternatively, each error message found in TSSs could be separately listed in the Error list.
My 10 second idea:
Resulting in the Error list perhaps showing it as either an error or concatenated into the Details:
Particularly for refactoring code, it would be nice to have a way to only apply changes to re-parented items if they already have a library/class layer in their icon. With other smaller utility VIs, using the Apply Icon To VIs action causes the layer to be added and then I have to go through and eliminate the created layer so the icons look correct again. I'm fine with that as the default behavior but I'd like to have an option to only update icons that already have the NI_Library icon layer for these kind of updates.
Hopefully low hanging fruit? I'm constantly checking the error list when working in a VI that's part of a broken class hierarchy to see if the VI itself has errors or if it's just due to a hierarchy error or dependency error. I often repeatedly check it to confirm if the VI I'm currently working in has the errors and could save a bunch of time if something was different about the broken run arrow and I only had to glance at it to confirm I can move elsewhere in my development as expected, or continue to the error list to see what's really broken.
Let's say I have a class with a few public VIs, and several private VIs and typedefs:
Assuming I'm not working on a VI within the class, If I'm using this class on a block diagram, I can only use the public VIs.
However, if I right-click on the class wire, and go to the auto-generated class palette, it shows everything. This can be absolutely overwhelming with larger classes. Why not scope this palette appropriately?
Currently if you flush an event queue that data is lost. Flushing and destroying and event queue should have the same interface as flushing/destroying a normal queue. Return the Data! I want the option to batch process the events, The code below would have to handle 1000 separate events to get the data out.
It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down. Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI. The tool should just work. "Ctrl+." doesn't always work. You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.
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:
I often work with DVRs, usually using typdefs or classes for the underlying data.
It's a serious pain to access the typdef or class from the DVR itself (control, indicator, or wire). There's no option for accessing this through the menu, and I often find myself dropping code in my block diagram to output the data type, then right-clicking on the data type and then from that menu opening the typdef or class.
The request: add a menu option for "Open Data Type Def." or "Show Data Class Library" to directly access the underlying type if it's a type def or class. This menu option could be exposed on wires, controls, and indicators.
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.
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.
I was almost certain this idea already existed, but I couldn't find it. If it does exist, please cross-link and disable this idea.
There are a coupe of functions which could really benefit from backwards propagation of data types. By this, I mean the ability to change a functions input datatypes based on a wired output.
Some functions already do this (like Variant to Data). However, that implementation has its flaws (as far as I can tell, the backwards propagation only works if wired to an indicator terminal).
Functions like Select, Obtain Queue, and Create User Event would benefit greatly from this (as well as many others).
Essentially, what I would like is a Type Specialization Structure that works backwards.
To implement this using today's technology, I guess we could create express VIs which have scripting function calls whenever the outputs are wired??? But that's janky and not practical for everyday development.
Simple example of Select
Here's a previous idea I posted, for this post, I'm proposing a generalized version of what I suggested there.
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).