It would be great if the right-click context menu on a case structure had small glyphs to the left of the text (think similar to the TortoiseSVN context menu for those that know what I am talking about).
The reason behind my request is that it often takes me quite a while (a few seconds really, but it slows me down), to figure out which menu item will duplicate a case and which will delete a case. For some reason my brain interprets duplicate and delete as the same and I always have to think about it.
A simple "+" glyph next to add, a "-" next to delete etc would go a long way to making those menu choices a lot simpler.
See attached pic for an mock up.
There are probably lots of menus that could benefit from something like this.
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:
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.
Providing additional Context Help information on Controls that contains information as to their "type" (Classic, System, Silver, etc.) as well as their font, font-size, and control-type (indicator, ring, enum, etc.) would be useful. The utility of this is obvious if you have ever had to modify/update an existing GUI and want to maintain the look and feel when adding new controls -- this would allow you to easily see what was previously used for the existing controls on a GUI. This "verbose" information could possibly be turned on/off as a Tools->Options->Front Panel setting.
It should be nice to limit the action of Ctrl-B to a selected part of the block diagram.
For the moment the Ctrl-B removes all brocken wires in the complete VI.
Sometime when you have a case structure with multiple cases ... and when you have multiple brocken wires in many cases ...It is usefull to keep non visible broken wires...
The broken arrow (list of pending errors) will then help you to find all locations to modify.
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.
Have you ever placed a background image on your front panel to make it look good, but then found that most of the controls and indicators covered everything up?
Ever wish LabVIEW had more appearance customization to make better looking GUIs?
I would like to propose an opacity slider control in the appearance settings tab of front panel object properties. The added setting would not make the entire objects opacity change; ideally the opacity control would only affect the borders and grey space. With this added control users can make better looking user interfaces without having to make custom controls.
Take a look at the difference:
Not Ideal Front Panel with background image and NO Opacity Control
Beautiful Front Panel with background image that you can still see by setting Opacity Control to 50%
Before and After Appearance Settings tab in the Properties Window for a waveform graph:
Currently the only easy way to implement a similar type of setting is go fully transparent by using the tools palette paintbrush tool and setting the color to transparent:
Kudos and share this idea if you want it to happen!
We have (collectively) complained about coercion dots many times on various LV forums -- they are nearly invisible and there are three different kinds, which require different levels of concern. The problem is that there are very few pixels within a terminal and there's no space for any pattern to differentiate the three kinds of coercion (and changing colors is a problem for reasons discussed here in the Idea Exchange).
Another LV developer had an idea that I liked: add an option to view giant coercion dots. We have avoided this because coercion dots bigger than the terminal would interfere with wiring. However, many developers have a policy of eliminating all coercion dots on their diagrams. For those who have such a policy, they could eliminate the coercion dots as they work, and thus might not see any problem from such large dots. Large dots would solve lots of other usability problems that coercion dots have today.
This option could be something in Tools>>Options, but I'd rather it be something in the View or Edit menus so it can be quickly toggled on or off with a shortcut key.
These graphics are "programmer art" -- I just made the three dots look different. Please sumit alternate images for the three dot types if you have better style suggestions. I did make the three dots differ in both pattern and color so that we avoid problems with colorblindness. The type-only was a solid dot, the widening coercion is a bulls eye, and the narrowing coercion is a single ring. Any redesign should definitely take colorblindess into account.
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've had enough! Your code does not have to look like this:
Or this:
You don't have to wire a string into Build Path's second input! It can take a relative path just fine! This is particularly helpful when building relative paths that involve climbing a directory structure. But it's also useful for building hard-coded folder paths, or even just specifying a file name:
I've seen code that looks like the first two images way too often, so I propose the following:
Change the name of the second input of the Build Path function to 'relative path or name'.
Change the default data type of this input (i.e. what it looks like when unwired) to path instead of string.
The function will still work fine with string inputs (so existing code is fine), but this approach encourages developers to actually use the path data type when working with paths. You should kudo this idea if you have ever (1) written code that looks like the first two images, (2) needed to explain to someone that they can wire a path into Build Path's second input, or (3) gotten burned by multi-platform issues when somebody typed path separators into a string wired into Build Path.
Title basically says it all but I'll elaborate. With increasing monitor resolution, a 16x16 glyph on a listbox doesn't work very well. On a 4K monitor this is awful tiny. This idea is to support larger glyphs in Listboxes, Multi-column Listboxes, and Trees. Glyphs are used in several places but on favorite of mine is to have item selection with checkboxes,example here. Allowing for these glyphs to grow with the row height would make them appear more cohesive. There is a threaddiscussing this topic, and a work around involving an array of picture rings that is placed over the listbox control. Here is a demo from that thread:
This work around is fine for simple things but doesn't scale well, and doesn't support trees easily. I for instance want to have two trees, where a user can drag and drop from one to the other with the larger glyphs coming along with the drop. Having to handle where the user dropped, and then dynamically building the glyphs to overlay on top of the tree, with indentation, and hiding when a tree's leaf is closedis a major pain. Please NI add a feature allowing for larger glyphs, and I would be so happy.
I really like having two different default locations for my terminal labels. What I do not like so much is that I still end up dragging a lot of labels around after changing a control to an indicator or indicator to control. I would like it if the label location was automatically moved to the default position when the direction of a terminal is changed.
You could get fancy and only move it if it is currently in the default location, I'd prefer it to always be moved. And I am not interested in the Quick Drop shortcut here. I do not want a quick way to clean up the mess I do not want the mess made in the first place.
All property nodes should use enums to make the code readable and not required to open help every time you need to set a properity. I find myself creating typeDefs for my self so I don't have to look up what the properity does and to make my code easier to edit. Example provided is to disable a control on the front panel. This is in the LabVIEW style guide
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.
Suggestion: Double clicking a connected terminal on the connector pane highlights and jumps to the connected control. This would be useful for controls that are off screen or hidden.
Similar behavior to double clicking the associated terminal/icon on the block diagram, where it automatically repositions the front panel's view.
