LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

In general I would like to see LabVIEW more in line with the OS GUI standards. We have dialog controls and colors, however they are not set up to be the default choice - and we lack other GUI elements like status bars, notify icons, child windows etc. etc. A large part of LV-programmers' time is spent on ways to get LV to mimic what users will recognise and therefor intuitively understand.

In this case I simply miss the "sort glyph" that indicates that a table or listbox is sorted based on a given column and in which direction.

I imagine we could show or hide this and set its direction with a property node...It would not handle the sorting (although that would have been neat as well - if you had an in-built sorting that just needed to know a few parameters about the column data to do the job)...

View All (1)

Abort All VIs in Project

When improperly stopping a project that has launched asynchronous vis set to fire and forget, you end up with classes and libraries that are locked.

There seems to be no way of unlocking them other than to close the project. There is an idea to abort called VIs when the parent stops but from the lack of kudos and by reading the comments it doesn't seem like a good one.

I know about and use the Abort.vi but it does not work in this case. The dropdown is empty:

Not even the LabVIEW Task Manager can help.

My idea is to have a button that does whatever closing the project does when it unlocks the class or library. Maybe this means it transparently closes the project and opens it again in the state it was in when the button was pressed. I don't know.

I know there are some similar ideas but as far as I can tell this is not a duplicate.

View All (3)

This is one of those existing "features" that I cannot understand, no matter how long I ponder why it is implemented this way. (WHY!!!?????). Somebody must have consciously programmed this behavior in the early days of LabVIEW, but I simply don't get it. 😉

Try the following yourself and you'll see what I mean: 😄

Create a structure (For loop, while loop, case, event, etc) with a few tunnels.
Select one of the tunnels, and, using the arrow keys move it towards one of the structure corners.
Observe: As soon as we move within a few pixels of the corner, the tunnel jumps to the corner and can no longer be moved with the arrow keys alone.
To move it away again, we need to grab it with the cursor using the mouse and move it at least a few pixels away from the corner or use "shift-arrow" to move it by a bigger step. THis should not be necessary.

Idea: There should be no such stickyness!

IF a tunnel is moved towards a structure corner with the arrow keys, it should simply stop moving at the corner and we should be able to move it away again by pressing the opposite arrow key (or the arrow key following around the corner by 90 degrees)

String functions with array input

I really, really don't like this behavior:

Whenever you use the KeyFocus property, or simply the tab key on a running VI, whatever control has key focus gets that ugly black border around it. Can we just eliminate this feature, or at the very least, have the ability to disable it? The border doesn't appear on System-style front panel controls, but it does for anything else. I've written all sorts of hacks over the years (the latest being in Quick Drop) where I have to figure out a way to hide that ugly border when a control gets key focus.

View All (5)

After reading Restore High Contrast Icons I procrastinated as long as possible before installing LV2016. When I finally did, I was disappointed by the additional space required for the palettes; all of them! I have been using LabVIEW since 5.0 and switched to an Icon view of the palettes shortly after getting comfortable with the graphics. Now, I have to move my mouse further to get to each sub-menu and VI selection. It's a waste of developer's time and apparently done for absolutely no good reason except to make a change; very similar to the washed out icons.

This extra space needs to be removed or at least an option provided to set the spacing back to the condensed spacing always available.

These images to show the relative size of the palettes LV2016 vs. 2015.

Controls Palette

Functions Palette

Yes, this might seem trivial, until you think about traversing several palettes to get to your needed VI.

*Random example, if one were doing FTP development they'd pin the menu.

** The original size of the above graphic is 1030 pixels wide; less than 800 for 2015.

Quit messing with what works and has become the standard with regards to options. At least when that ridiculous "default" setting for icons instead of terminals was introduced we could undo the setting in Options.

It seems that NI has hired some non-G experts to mess up the interface simply so they can enumerate all the "great" improvements they've made. Or, was all the extra space to make sure newbies couldn't miss the folder tab, since connecting the "right arrow" on an icon to it being a sub-folder would be too difficult for children?

I find myself with my fingers on the shift and arrow keys a significant amount of time while trying to make my code more readable. Invariable I switch between the arrow keys and the mouse in the process of straitening and aligning. Why not use the arrow keys for both alignment and object movement?

I'll let the following illustrations explain what I mean. I'm only showing a limited subset of the possible combinations, most of the time you can go in all 4 directions.

Note that during a "combo" (the control key isn't released) the original order of the objects will need to be remembered, so that when they are all aligned into a corner, subsequent combinations will maintain the order.

Building on that, more advanced functions are below:

For the diagonal, once they are aligned to a corner, the diagonal can go in any of the 4 directions.

As you can see, this will emmensely increase productivity and general neatness of code. And perhaps more importantly, it will bring us even closer to our ultimate goal: making LabVIEW programming even more like playing a video game.

Malleable Probes

View All (1)

You might not know this, but if you drop a String constant on the block diagram (or create one from a terminal), you can use shift+enter to define the bounds as you type.

You start typing the first line. As you type, the constant gets larger. Hit shift+enter. Now as you continue typing, the string constant grows vertically only, using word wrap at the bounds of the string constant. Now hit shift+enter again. The string stops growing vertically and the vertical scrollbar appears on the constant.

This behavior is very nice for creating string constants inside of structure nodes without having to create the item, then resize it, then come back and start typing your text.

Wouldn't it be nice if the same shift+enter trick worked when typing free labels? I think so.

View All (5)

If You drag a tunnel of a loop, case structure or any other structure along the border over a corner, then

the connected wire becomes hidden behind the frame.

Sometimes, the wire looks alike it is connected to another wire instead - like in the example below.

I fell into that trap, because I've just seen the frame to the right and didn't expect, that the wire was

connected to the tunnel near the bottom.

Wouldn't it be great to break up the wire with a 90° corner and place it in the visible area?

More similar situations like this are posted in this thread:

http://forums.ni.com/t5/LabVIEW/wire-vanishes-behind-frame-of-case-structure/td-p/3221167

Explore from Getting Started Window

View All (3)

Hide This VI label as default

View All (1)

Wire a Case Structure with an enum. Now pop up on it and select "Add Case For Every Value." In today's LabVIEW, this adds new frames to the structure so that every enum value is handled by a unique frame. This makes creating the structure initially easy, and it gives you a way to walk through and make sure that you've filled in code for every frame. But today, the Case Structure has includes the "Default" case when the Case Structure is first wired. That is done so that wiring a Case Structure with an enum does not result in a broken VI. When a programmer provides a unique case for every value, the Default state is now redundant, and the only thing it does is create the potential for error if you ever add to the enum. Thus I would propose that if you use "Add Case For Every Value", then LV should remove the Default tag from the first case.

View All (4)

Currently the only image formats still commonly used today that can be imported into custom controls are non-scalable bitmap formats. The only supported vector formats that I know of are WMF and EMF, which is almost never used anymore to my knowledge. Even worse, it doesn't support features now expected in vector formats, such as gradients and alpha transparency. So if you're developing a custom control, you have to either use an antiquated format or a bitmap format.

LabVIEW 2011 introduced the new Silver control set, which to my knowledge still use LabVIEW's internal PICC format, which is completely undocumented. Rather than adding gradients and other new features to this private, undocumented format and using that, it would have made a lot more sense to add support for SVG, a modern, full-featured vector format that is commonly used, and used that for the Silver controls.

Not only are the two vector formats LabVIEW supports ancient formats, but their inclusion almost seems like an afterthought. Imported WMF and EMF images aren't anti-aliased like the Silver controls. Because of this, it's practically impossible to create any modern-looking custom controls that look good scaled unless you don't want any diagonal lines or curves, in which case you might as well just use a bitmap.

Sorry for the abrupt end!

View All (6)

I saw this idea which I really liked and I realised that this would also be nice.....I do this type of 'insert subVI, delete broken wires' action all day.

I searched I think what I am proposing is a little similar to this idea but I think in the difference with the idea I'm putting forward is that labview will only automatically delete a section of the broken wire when the 'short circuit' is sending data around a VI as well as through it!

The second part of the idea - where the 'merge errors' vi can be configured to appear automatically when two 'sources' are wired to one sink would be useful when you are parallelising subVIs on the block diagram. I'd also suggest that if this option is configured and the source wires are deleted (so that only one source is linked to one sink) have the merge error vi disappear!!!

I'll be gutted if I've wasted my time on another duplicate.....I keep not finding other peoples great ideas

View All (2)

LabVIEW Idea Exchange

Sort arrow in column headers of tables and listboxes

Abort All VIs in Project

If diff has no panel differences, show the block diagram on top

Make structure corners non-magnetic for tunnels.

String functions with array input

"Flip" windows between front panel/diagram

Make text search look inside error ring constants

Key Focus Surrounding Border - Let's Get Rid of It!

Change function for all Items similar like "Compound Arithmetic"

Eliminate Palette Space added with LV2016

Use arrow keys for object alignment

Malleable Probes

Shift-Enter should define word wrap bounds on Free Labels

Avoid hidden wires when a tunnel is dragged to another border

Explore from Getting Started Window

Hide This VI label as default

programmatically create and delete controls dynamically at run time (G Type?)

On Case Structure, ""Add Case For Every Value" menu option should delete Default

Add support for SVG images in custom controls

Automatically delete broken wire section which 'shortcircuit' a subVI