LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Build/Index array element index tip

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)

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)

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

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)

I am experimenting with the Idea Exchange here. I am suggesting a premise and leaving implementation details aside.

Premise: When a control is placed on the FP, its terminal must be placed on the top level diagram.

The rest are negotiable implementation details, I want to establish consensus on the premise and let NI do their job of figuring it out.

As you know, the current placement algorithm is some form of random dart tossing. No regard is given to structures, or other code which is lying around. It is easy to sneak a terminal into some random case structure resulting in an easter egg hunt or annoying visit to the FP.

This idea: at the very least, put them on empty space in the top level diagram.

One possibility is the following idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Unused-items-tray/idi-p/1391958

There are others.

Spoiler

Of course Icon View makes it much harder for them to hide....

New primitive: Rename Event

Hi.

When you register a user event the name of that event (the name that appears in the event structure selector) is determined by the last output terminal that event emerged from. If your user event came directly from the Create User Event primitive your event will of course carry the name you gave it on its data type, so no problem there. If your event came from a control terminal you are (usually) also in control of the name your event wire carries (as it will be the control label), but if your event wire came out of another primitive along the way your event name will in some cases have changed to something you don't control yourself. In some cases your event name will just be <User event> or even <?>:

One of such events is annoying but can be acceptable. It's worse when you have several of those in your event structure selector - which of the <?> belongs to which user event? Therefore I usually rename events on the wire if they catch a generic name along the way. I use the Variant To Data primitive for this:

The above is the best solution currently, but it has a couple of drawbacks most of which come in effect if the data type of your event changes. In this case you risk ending up with code that isn't broken but executes with runtime errors. Therefore I suggest a new LabVIEW primitive for renaming events - one that will automatically carry over the event data type:

Would that be useful for anybody else but me?

Merry Christmas,

Steen

View All (3)

Behaviour of Numeric constants

View All (2)

LabVIEW Idea Exchange

Build/Index array element index tip

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

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

Show running clones while browsing relationships>Reentrant Items

Editor hints for miswires?

Allow Query Input Devices to return all available Devices

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

Control terminals should always be created on the top level diagram

New primitive: Rename Event

Behaviour of Numeric constants