LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

If you click in empty space on a block diagram, then press any of the arrow keys on the keyboard, nothing happens. I propose that this action should pan the block diagram. This idea hit me while huddled in an airplane seat trying to review some block diagrams - it was a laborious task trying to pan using the laptop touchpad that would have been greatly simplified by just using keyboard arrows. This intuitive action is already standard in web browsers and popular document editing software.

View All (6)

I was very happy when NI implemented this feature in LabVIEW, but was disappointed when it was not implemented in many other programs I use.

In most other programs that have this feature, the selection order determines the "home" position for the alignment. For example, If I select 3 objects ans alogn left, LV aligns to the left-most object. Other programs align to the left of the first object selected. This is particularly useful for centering objects, as LV uses a calculated center line, so I am constantly readjusting or temporarily grouping objects to try to get things where I need them to be. If I had one object where I wanted it, I could select that first, then center everything else to it. (I admit it will take some getting used to at this point, but it would at least be consistent with how the feature is used elsewhere).
Allow locked objects to be selected for alignment. Just because it is locked doesn't mean I don't want to use it for alignment purposes. Obviously, I don't want it to move, but it would be nice to be able to select it without having to unlock it, align, then relock.
I would like to see an align with pane option as well. This is most useful for centering, but I would also have some use for it when I am trying to put an abject right a the corner of the pane.

View All (5)

The convolution tools have polymorphic instances for 1D and 2D data.

The 2D instances have a very useful input to control the output size (full, size X, compact).

The 1D instances don't have this input (Why?!). In the vast majority of my 1D convolution applications, I would prefer a "size x" behavior for the output, making the output size identical to the input spectrum, no matter the size of the convolution kernel. If the 1D convolutions would accept this option, performance and inplaceness could possibly be optimized compared to a manual trimming later.

Suggestion:

All convolution instances need an "output size" input, not just the 2D versions.

"To FXP" must accept array data

With small front panels (in X dimension), Align Objects, Distribute Objects and Resize Objects (in the toolbar) are outside the visible part of the front panel.

This makes the alignement/distribution/resizing a little bit longer :

Resize the front panel to make the tools visible
Make the alignement/distribution/resizing
Restore the size of the front panel

Keyboard shortcuts or even better a specific palette (like Controls or Tools palette) would avoid these additional steps.

View All (1)

View All (3)

Currently, for waveform/XY plots/graphs, the legend, graph palette, cursor window, etc are all "coupled" with the graph itself from a "graphical" perspective.

This means that all of these "addons" must be attached to the graph, and you can't put them in a different part of the panel. Screen resizing thus tends to screw things up, especially if your plot names can be defined by the user.

I'd like to decouple these somehow.

For example, I'd like to be able to put my legend and zoom tools in separate panes separated by splitter bars, or even in a right-click style menu (like a subpanel popping up). This feature would let you use automatic resizing on the plot itself and keep the legend separate.

You could theoretically program your own version of this, but:

-Recreating the legend functionality (line size/width/etc) would be a large undertaking, especially since there isn't a native Datagrid type control that could display a checkbox, string, and small image.

-I don't know of a way to get at the built-in zoom/pan tools programmatically (yes, you could create your own, but it's a big PITA)

-It wouldn't work at edit time, like the current features do, unless you baked all of it into an Xcontrol

Basically yes, you COULD get a lot of this done yourself... but it'd be nice to just use the tools NI already made, which work great. I don't want to reinvent the wheel just for some graphical convenience.

While writing/debugging applications that make heavy use of reentrancy it is not uncommon for a reentrant VI to be left open after the rest of the application has shut down. This leaves VIs, Classes, LVLIBs locked in the project and your only recourse is to hunt down the offending reentrant item or close the project and reopen it.

It would be valuable to be able to see the running clones in the list of reentrant items found by navigating to View>>Browse Relationships>>Reentrant Items, maybe denoted by a *, like this below:

Having that would easily allow me to open the running clones and close them out manually so I can continue debugging.

View All (2)

Okay so lets say you have a VI that you developed, and works great on its own. You have some nice scaling and control manipulation with panes and custom resizing code. All works great. Then you realize this might be handy to have in a subpanel. So you insert it into a subpanel, which itself can be resized at runtime. The only problem is, if code isn't written to handle the resize of the Subpanel properly, then the user could accidentally make the subpanel smaller than the minimum VI size that is inserted into it. At which point the UI will get messed up and making the subpanel larger will not bring it back to the desired look. Here is a thread where I post a simple example. If the subpanel is set to fit to a pane, then you could programatically set the minimum pane size, to be the same as the minimum front panel window size, of the VI being inserted.

But if the Subpanel isn't in a pane, then there could be other issues. So this idea is to have a property of a Subpanel that is "Minimum Subpanel Size". Which will not allow the control to be smaller than a set size. To make things even easier I propose a property that is "Set Minimum Subpanel Size to Minimum Front Panel Size". Now when you try to make the Subpanel too small with a property node, it will generate an error, just like if you try to set the Front Panel too small with a property node. And if the Subpanel is in a pane and being resized, this would prevent the control from getting smaller, and prevent the pane from getting smaller.

Editor hints for miswires?

Here's a dumb mistake I think many of us can relate to:

It would be really nice if the VI were just broken in this situation. But I can understand why it's not necessarily simple to mark node *outputs* as required.

But maybe there could be a way for the editor to *hint* that there is a problem here. Maybe the bundle nodes could change color when the output terminal is wired, so you could get a little more obvious feedback if you screwed up like this. The same could go for any other primitives that have a "for type" input (e.g. unflatten from string, variant to data, to more specific class, etc).

Granted, VI Analyzer could report bugs like this, but having a little more immediate feedback would probably be a big win.

(Let me know if this should be cross-posted to the NXG idea exchange, too).

View All (3)

LabVIEW's Query Input Devices uses LVInput.dll to return information about the Keyboard(s), Mouse(s), and Joystick(s). However, it appears that the number of Joystick entries returned is limited to 8, whereas on several machines that I've examined, the "joystick" device can be present in slot 10 (as noted by DxDiag's Input test, which otherwise matches what LabVIEW returns in the first 8 slots).

Can this function, which returns an Array, be modified to return as many entries as the DxDiag utility returns for DirectInput? This would facilitate using multiple joystick-like devices as control units using standard LabVIEW procedures.

Bob Schor

Right now the only way possible to set the tabbing order of controls on the front panel of a (sub)VI is to use Edit >> Set Tabbing Order.

I would like a VI Server property/method to be able to programmatically set the tabbing order of the controls on the front panel the way I want. This way I can write a script to fix a large number of VIs without needing to manually click through each one. (Of course I would be responsible for programmatically figuring out the order I wanted, but I could make some general assumptions like following the top-bottom left-right on the front panel existing layout, or following how they are connected to the connector pane, etc)

Multiple Line Pattern in the Browse Options

As requested by this fellow 8 years ago: http://forums.ni.com/t5/LabVIEW/Multiple-pattern-lines-in-path-s-Browse-Option/m-p/776968/highlight/true#M355522, it would simplify some GUI if the user could select from a drop-down list, which files to look for in a File Dialog pop-up window.

Currently, we get a single line:

This results in this kind of mess courtesy of the IMAQ Load Image Dialog.vi):

To update the snapshot illustrating this other thread, here is an example of MS Word in action, illustrating the desired behavior:

In other words, it helps cleaning up the results, while using a single dialog window for all kinds of different files (which will be dealt with differently down the line).

I am not sure how multiplatform that can be, but here is the file open dialog options from TextWrangler on MacOS:

so it seems that can be done.

The thread I am referring to had a link to a Windows API call, but the link is dead (probably the result of the recent disastrous site cleanup). And of course is not multiplatform.

View All (2)

This should be simple....(!?)

I want my user to be able to resize the window but only in one dimension - e.g. drag the right border of the front panel right or left but not allow them to resize the height while the VI is running. (In my current project it just doesn't make sense to allow them to do this).

I have to keep rewriting the front panel size on the resize events but it has ugly side effects (parts of the front panel become visible temporarily until LabVIEW puts the bottom border back, amongst other things).

The VI properties can disable resizing completely but it should be easy to add a couple of sub checkboxes for Height and Width.

I'd like to see those properties reflected in the usual places (property node etc).

Support didn't have a better solution than the code I have but suggested that I put in an idea .... so this is it!

View All (4)

A shortcut menu like this one would easily move a label by right clicking the label and selecting the snap location.

The move would not change the locked state of the label.

Only the label should change position, the control should remain anchored.

It would especially make the middle right and middle left positions much easier to get to on single-line controls.

The mockup is purposefully large to give visual distinction between locations. It could instead be more compact, but this worked for an example.

View All (5)

Fix the System Numerics

The System Numerics are driving me crazy! My wants are simple, a radix display and increment/decrement controls.

System Spinner = Increment/decrement but no radix. Why the property page gives you the option is a mystery.

System Numeric = Radix but no increment/decrement. Argh.

When you have the default style set to System, the created controls leave you in no-mans land. A system spinner with invisible spinners. If you wanted a spinner, you have to make them visible. If you wanted a numeric with radix you have to replace, and then resize. It seems nobody is happy.

I seem to want the numeric more often than the spinner myself, I would be happier if it was the default.

Bugs: there are issues with the property pages versus right-click menu settings (LV9 hopefully fixed). Besides giving you false hope with the radix display of the spinner, the checkboxes for increment/decrement do not always reflect the current state. It often shows up unchecked even when they are visible. Just adds to the fun.

tl;dr : Make a single system numeric with both radix display and increment/decrement buttons.

Ignore resize property

When you want to make a resizable front panel there are only few possibilities, especially if you don't want all your front panel beeing resized.

Splitters are great but you can't always use it, in a tab control for instance it's impossible (and someone already suggested this idea here, sad it's not implemented ).

You can do it programmatically (lot of work!), maybe with an XControl depending on your application (lot of work too!) or you can also Scale Object with pane with only ONE object.

There's still one option: Scale all front panel objects when resizing

Why not improving this method by adding an Ignore Resize property?

It might be easier to implement for developers compared to modifying tab control and would be really easy to use !

View All (2)

In order to make publication quality graphs in another program, I needed to use "export simplified image" many times, each time exporting to the clipboard as emf with the grid hidden.

Every time, this dialog comes up, all settings are back at the default (bmp, grid shown) and I have to click a few places before being able to do what I want. I think it would be more user friendly if this dialog would remember the last used settings, at least during the current session.

(I also think that "hide grid" should be checked by default)

IDEA: This dialog should remember the last use settings during a session.

View All (5)

LabVIEW Idea Exchange

Use Keyboard Arrow Keys to Pan Block Diagram

Rework front panel object alignment

Output size configuration for 1D convolution

"To FXP" must accept array data

Keyboard shortcuts or palette for align, distribute and resize objects tools

Introducing "Quick Classes" (an all-graphical way to define classes and anonymous functions all in one)

Decouple plot legend/tools/etc from the plot graphic itself

Show running clones while browsing relationships>Reentrant Items

Set Subpanel Minimum Size (optionally set to the inserted VI FP minimum)

Editor hints for miswires?

Allow Query Input Devices to return all available Devices

Add ability to programmatically set tabbing order of controls

Multiple Line Pattern in the Browse Options

Shorten the Drop event "Available Data Names" element

Property to get LabView Editor bitness 32bit / 64bit and patch level

Independent control for user resizing front panel horizontally and vertically

Snap Label to Position from Right-Click Menu

Fix the System Numerics

Ignore resize property

Export simplified image should retain settings during a session