LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Properties or parameters of methods are often documented (context help ctrl+h, move mouse over properties/methods). When a control is created to apply data to a property node or a method parameter, the available documentation of a property/method parameter should automatically be added to the controls documentation (description).

Example: The following picture shows a subVI of a LabView driver basing on an Ag3352x IVI-COM driver. Documentation for the amplitude property is available. When the amplitude control is created, the available documentation should be added automatically to the controls description...

Directory History

After a brief search I didn't see this one yet:

As I'm gradually changing over my wire labels to the "new" method, I'm noticing some quirks regarding positioning. I'd like to suggest the following:

Let the font in these labels default to "centered", or at least allow the user to configure the default font on these.
Add an option to automatically center wire labels on the wire segment's midpoint.

I'd like to emphasize the "option" part on the latter, as this understandably won't be a good fit for every context.

As with other suggestions, I realize that this is somewhat subjective, so here's an example of how I'd like to use the labels.

Here I've aligned all of my labels on their horizontal centers and have set the respective fonts to center justified. My intuition tells me that, now when I start typing, all of these labels should remain aligned on their horizontal centers. However, when I started typing out "Enable Speed Per Air Flow Rate", the whole label started wandering off to the left. I don't quite understand how the alignment works, but it's not proving efficient in most of the instances in which I use it.

Thoughts? Improvements on this suggestion?

Thanks as always,

Jim

In LabVIEW 2009 one could right-click on a VI, for instance, in the project Files view and select a Delete from Files option. (It didn't work perfectly--in particular, LabVIEW didn't always delete folders from disk, but it usually did work for individual VIs.) NI removed this option in 2010, leaving the developer with the task of deleting files manually through the OS files view. (This isn't the end of the world, of course, if a developer doesn't use integrated version control--and we don't currently but only because LabVIEW does not properly support integration with Subversion--but it is a significant inconvenience.) This option ought to be present once more.

In particular, this function is absolutely required if LabVIEW makes a claim to provide integrated support of version control. On that note, the current client (Pusk Ok SVN) LabVIEW supports for what is probably the most popular version control provider (Subversion) among its customers does not even claim to support file renaming or deletion (http://www.pushok.com/soft_svn.php), while a third party plug-in (http://jkisoft.com/tortoisesvn-tool/docs/) claims to support this behavior only for VIs and Controls (not, for example, LabVIEW class files).

View All (6)

The Application refnum method "All VIs In Memory" returns a list of VIs. This list includes the instance VIs created by Express VI nodes. This list includes private data controls of classes. It does not include the clones of reentrant VIs.

It would be nice to either add some parameters to this method or add some new methods to get some different behaviors, including:

"VIs In Memory That Actually Exist On Disk" -- would not include instance VIs or private data controls

"Really All VIs In Memory" -- would include the reentrant clones

These are the two I most commonly wish we had. There may be other commonly used variations that would be worth including.

View All (1)

Whilst developing code I often need multiple copies of a subvi on my block digram. I create my duplications by click-dragging with CTRL pressed, which creates a copy. To make sure the copy is aligned horizontally with the original you can press the Shift key as well to enforce motion in one direction only (horizontal / vertical). However, this only works if you think to press the Shift key before you start the drag operation. Pressing it afterwards has no effect.

Furthermore, once a motion has begun, the chosen direction is the only allowable direction the object can be moved in. In other programs it's quite typical to restrict the motion to the direction of most linear travel from the origin, so moving back out to the right would restrict motion to horizontal, but then moving the mouse to somewhere above the origin would restrict the movement to vertical only.

I'd like to see these modifications introduced, purely to improve the development experience.

Note: This idea is the consequence of this original (flawed) idea

Windows based Folder dialog

Would be nice to finally see the folder dialog that every user is used to from Windows instead of using the very confusing LabVIEW implementation.

Download All

View All (4)

Pretty self explanatory.

Place an image on the front panel.

Use the "Get Color" Tool from the tools palette on a color on the image.

The foreground color should ideally be the color you clicked on, however it's always Black with a White Background.

I'd think that getting colors from an image should work like getting colors from anything else on the front panel. It would be pretty nice to be able to match the FP elements with an image thats on it for better GUI design.

I like using User Events.

I find them intuitive for (certain) communication between code modules.

One thing bugs me though. If I decide to keep the Event private to a certain module and only release a pre-registered User Event (registered for each listener) careless code can bring the entire communication to a halt. The bare User Event refnum (pre-registration if you wish) is exposed within the Event Structure. I have yet to understand wha this is but whatever the reason, it essentially means that it's a serious problem for 1 to n communication. If one of the n listeners decides to destroy the user event, communication to ALL listeners is destroyed.

I wish we could set the User Event refnum to being private so that it would NOT be exposed within the Event Structure.

Shane.

View All (3)

View All (6)

View All (3)

If you have disable symbols that switches code into debug or demo mode etc....it is critical that you know about them, and see what they are currently set to.

Conditional disable symbols are too hidden; to see what they are and edit them you need to right click the project, select properties, and then select the symbols option from the properties window...

Idea 1: Put them in a folder in the project list instead and allow the user to edit their value directly in the project window.

Idea 2: In addition all symbols should have a setting that says what their value should be in a built application, this could be settable either by double-clicking the symbol in the symbol folder, or by showing the two values directly in the project window in two separate editable columns.

This would also eliminate the need for this related idea.

PS. The suggested symbols folder has another related idea - namely the idea for an equivalent to "DEFINE" in C. Definitions could be a folder much like the proposed symbols folder, or they could be merged.

View All (2)

I find that there are WAY too many steps to setting up a custom button with up, down and hover graphics. And there is too little documentation on this subject as well. Here are the steps I have to use to build a simple button from 3 basic png files (for the 3 states):

• Drop System button on front panel

• Right click menu > Advanced > Customize button.

• From control editor, choose customize mode.

• From the right click menu on the button:

1. Import from File
2. Select normal button image.
3. Copy to Clipboard
4. Select third picture item
5. Import Picture From Clipboard.
6. Select second picture item
7. Import from File
8. Select ‘down’ button image.
9. Copy to Clipboard
10. Select fourth picture item
11. Import Picture From Clipboard.
12. Select sixth picture item
13. Import Picture From Clipboard.
14. Select fifth picture item
15. Import from File
16. Select ‘hover’ button image.

• Change back to edit mode.

• Save control.

There has to be a better way!

View All (4)

Menu Upgrades

A few upgrades to runtime menus would be nice.

1. Allow for visibility on menu items. Currently there is only the ability to disable or delete a menu option. Disable is not often what is needed but deleting a menu item requires rebuilding the menu programatically. Why not just have a show hide property on each menu item.

2. Allow for a glyph/icon to be added to a menu item. This is similar to list boxes. The advantage here is that a psuedo-toolbar could easily be created using a menu. Also modern menue systems are adding this feature so me should have it in our toolbox as well.

3. Allow for detachable menus. This could be a stretch to ask for since it is more difficult to implement.

Sometimes I know I want an initiaized shift register, but I am not sure about the data type, because it might change during program development. Sometimes I have a cluster holding a few variables, but later I need to add a few more elements.

If I initialize the shift register with a diagram constant, things break whenever I change the cluster inside the loop and I need to redo the diagram constant by "delete the constant, right-click the SR, create constant".

I would prefer a mode where the initialization is generic and simply adapts to whatever type is wired from the inside. This simply ensures that no data is retained between calls, just between iterations of the loop as often needed.

In summary, we should have an option to generically initialize a SR (or feedback node) and it would look different to indicate that fact. For example it could have a small cap as in the attached image.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

Some languages like Rust and Zig have a feature called Tagged Enums (or Sum Types) that allow you to create a data type that can be one of a few different types where there is a name associated with each type. In LabVIEW, however, Enums are limited to consecutive numeric integer values -- there's no way to associate a type with each named value.

The power of combining an Enum with a data type for each value is that we could potentially use a Case Structure as a switch statement with type assertion and data conversion built in! This would allow us to create robust, type-safe code that is easier to maintain and understand.

See this github repository for a more complete proposal and an example implementation that gets us closer to achieving this in LabVIEW.

View All (1)

LabVIEW Idea Exchange

Auto increment alphabetically control labels

Add documentation to a control/indicator created from external code (DLL or .NET Assembly) tied objects automatically

Directory History

Wire Label Centering and General Position

Restore "Delete from Disk" in project Files view

Give "All VIs In Memory" some parameters or create alternative methods

Alter the application of Shift key presses to restrict motion whether pressed before or after dragging an object

Windows based Folder dialog

Get color (Color picker) should get colors from images on front panel

clean up option - "force error wire horizontal"

Don't expose the Refnum to a pre-registered User Event within the Event Structure

Highlight current selection in the remaining graph menus

Make Build Error Window Floating, Not Modal

Breakpoint Manager like Probe Watch Window

Make conditional disable symbols easier to access

Improve the control editor (especially for making custom buttons)

Allow breaking up long wires with labels in each end

Menu Upgrades

Generic shift register initialization

"Enumerated Variant" Data Type (like Rust and Zig have)