LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

Bookmark manager is extremely useful for navigating large code bases. Every feature I have in flight, I've got marks for all my expected or in-progress work. Sometimes I'm using it to navigate through related chunks of code. So I'm constantly referencing it. But it gets buried behind windows, just like the equally useful Error List Window. I'm constantly reopening both, but the Error List Window has a quick hotkey to bring it to the front (ctrl+L). I'm finding more and more that I want Bookmark Manager to have a hotkey too.

I've edited my personal menus to have "ctrl+," as the shortcut key, but I wish I could grab ctrl+k as a better mnemonic. Ctrl+k is currently paired with ctrl+j for bring to front and back... and those are keys that cannot be reassigned by users because they aren't main menu items. Personally, I'd place higher priority on accessing Bookmark Manager than reordering zplane, but I understand I might not be in the majority there.

Anyway, the idea is for some standard key to be assigned to the View>>Bookmark Manager menu item.

View All (1)

Many people do not realize that memory allocated by a queue is never deallocated until the queue is destroyed or the call-chain that created the queue stops running. This is problematic for queues that are opened at the beginning of the application and used throughout because all of the queues will always retain their maximum size, causing the application to potentially hold a lot of memory that is currently unused or seldomly used.

Consider a consumer that occassionally lags behind and the size of a queue will grow tremendously. Then the consumer picks back up and services the elements out of the queue in a short period of time. It is unlikely the queue will be this large again for quite some time, but unfortunately no memory will be deallocated.

I'd like a primitive that will deallocate all of that memory down to just the current number of elements in the queue. Since the queue won't need that much memory again for a long time and the queue will auto-grow again as needed, I'd like to recover that memory now instead of waiting for the application to be restarted (which is currently the only time the queue is created.)

The alternative is to add some code to periodically force destroy the queue and have the consumer gracefully handle the error and open a new reference. Then replicate this change for all queues. Seems messy and puts too much responsibility on the consumer. I'd rather just periodically call a 'deallocate queue memory' primitive on the queue reference within the producer, perhaps once every few minutes, just to be sure none of the queues are needlessly holding a large amount of memory.

I believe this will:

Improve performance in other areas of the application because less time will be spent looking for available memory to allocate.
Reduce the chance of Out of Memory errors because large blocks of memory will not be held [much] longer than they are needed.
Improve the common user opinion that LabVIEW applications are memory hogs or leaky.

I realize this will hurt enqueue performance when the queue begins to grow quickly again, but this area is not a bottleneck for my application.

Thanks!

View All (1)

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire. I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal. I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

1. Wire this specific VIM on error wires most often

2. Likely don't want the VI to stall in the event of an error

3. Would prefer to see that error propagated as quickly as possible like most other VIs do

Thoughts?

I have a few VIs with many events in the event structure ( and I'm sure there are apps out there with orders of magnitude more events defined).

In an effort to get this list under control, why not employ the same structure used when we edit an event?

Or, at least, offer it as an option(?)

Below is what the event-list might look like if it used the same organizational structure as the IDE uses to present available events when editing them. Below that is what the option-dialog might look like, and, far below is what we have now (I used screenshots from LV20014 , but checked LV2017 to see if anything had changed by then. 😁).

View All (3)

Taking this comment and making it an idea on its own.

Numeric controls can be configured to display their value today as SI Notation, decimal, octal, hex or binary by enabling Visible Items >> Radix and then setting the radix ring to the desired value.

This proposal is to add a new option to the ring for unsigned integer types: ASCII. This would cause an integer to be displayed as a series of characters as each byte of the integer is interpreted on the standard ASCII table.

(If in the future LV improves support for unicode string handling, adding a radix mode for "Unicode" might also be good, though at that point you'd have to specify an decoding to use for the individual control)

Note that adding this option to the Radix ring would really invalidate calling it "radix". Having "SI Notation" in the ring is already stretching the definition, but this would push it over the edge, so we might want to call it "Display format" or something like that. Or perhaps there's an alternative way of specifying this display mode that would be better (everyone, put your suggestions in comments below), but the main thrust of the idea is to let a number be shown using its character interpretation.

View All (4)

When you select a portion of code to create a sub vi, the logic that names the contorls on the sub-vi makes some bad choices. For example:

In the block diagram above, the selected portion of code will be used to create the sub-vi.

The resulting sub-vi front panel looks like this:

Notice that the input control inherited the name of the control from the parent but the output did not. Also note that the error output control inherited the name of the output from the sub-vi inside the new sub-vi, but the input error did not and ends up with the name 'error out 2'. This of course would NEVER be the right name for this control.

It would be a lot smarter if the new sub-VI inputs would inherit their names from the inputs of the functions inside the sub-vi since that more accurately describes what they will do with those controls. Also, I think the output indicators should inherit their names from the original destinations in the parent VI since that more accurately describes the data they will contain once the sub-vi executes.

The current behavior seems to be exactly the opposite of what a developer would want.

View All (1)

This idea is somewhat similar to Shrink-Wrap-Structures but for comments and strings

The idea is to resize a comment or string to the text by double clicking one of the resize indicators around the box.

This would happen without changing the number of lines or words on each line.

resize double click.png

The process would be resize the horizontal direction of the box until the line layout looks nice (and fits!) then double click the corner to remove the unwanted space.

There could be different resize processes depending on the corner or edge you click eg. double clicking bottom middle resizes to only remove vertical space, top left would resize and shift the text down and right so the bottom right corner remains anchored.

There are some other ideas about resizing multi line comment boxes but none were quite as straight forward as this so I made a new post for it.

This mechanism is similar to other programs for resizing boxes so it seems like a sensible thing to implement.

Insert class VI contextual menu

View All (3)

The Open/Create/Replace File Function with the Create operation does not create the file if the specified path leading to that file does not already exist. One has to use the separate Check if File or Folder Exists vi followed by the separate Create Function to first create the folder if it is found to not already exist and then actually Create the file with Open/Create/Replace File. It would be useful to not have to perform the already exists operation and simply provide the capability (perhaps as an input boolean option) to create the entire file's folder path if it does not already exist when using the Open/Create/Replace File Function to create a file.

Steve

View All (1)

Hello,

Today, ActivX and DotNet events are treated as callbacks ... ( A vi is linked to a callback )

It should be nice to handle them as LabVIEW events, so the callback treatments could appear in the LabVIEW event loop structure.

I think there is certainly a difference between events and call back handling, but it should be a way to standardize the "event/callback" view.

=> It would be more "user friendly" ... and applications could be more "maintenable" ...

Manu.net

View All (1)

Relative Path Node

I'd like to work with relative paths at a higher level of abstraction.

I often use path constants in block diagrams, and almost always I need relative paths. I love Browse for Path option on the file path constant. Inconveniently, I end up with an absolute path when I browse like that, then have to manually select the front end of the path, and drop a few other nodes and wires to specify what the path is relative to. The resulting code looks like this:

Four Relative Paths LabVIEW 2019

Note that the path 3 and path 4 are identical.

I would like to see a single node that:

Lets us specify what the path is relative to,
Lets us browse for a path like the file constant, and
Displays relative path without manual editing.

Here is what the code displayed above would simplify to:

Four Relative Paths with New Node

I'd like the base path selection to include options consistent with those from the file palette. One way to do this is to have a shallow hierarchy like this:

LabVIEW
- Application Directory
- Current VI's Directory
- Default Data Directory
- Default Directory
- Temporary Directory
- VI Library
System
- User Home
- User Desktop
- User Documents
- User Application Data
- User Preferences
- User Temporary
- Public Documents
- Public Application Data
- Public Preferences
- Public Cache
- System Core Libraries
- System Installed Libraries
- Application Files
- Boot Volume Root

This idea is based on the discussion from the Path Constants Relative to the Current VI's Directory Path idea. I'd like to thank AristosQueue and crossrulz for their feedback on that thread.

I think LabVIEW should have something like the dialog VIs that acts as a popup where the vi displays a message to the user but doesn't hang up code and wait on the user to press a button.

An example case is a state machine that has error checking built in errors out. Instead of creating a more complex error handling scheme to display the state machine errored out and heres why then shutdown the state machine, you could instead drop this async popup in the state with the message to display the error occurred then have the state machine shutdown like normal. This way, the user knows "the state machine shutdown for X reason" while the state machine also goes into a safe state.

I think the async popup is easier to trace since the error message is located in that section that detected the error vs having some sort of store an error string then in the shut down case read if there is an error and if so display the error once the station is already shutdown. Additionally, you cold see where all asnyc message blocks are via dropping one in your code then right clicking and searching for all instances. This could streamline the process to see where the fault occurred since the async message block would be in the location of the fault itself.

I have currently built something like this that is a reentrant VI whose input is a string and a secondary VI that launches the display message VI. It's a bit of a work around, but I can display a message to the user while my code continues to do whatever it needs to.

View All (2)

Create a "User Control Ended" Event

I need to detect when a user has released mouse control of a slider, but that is not possible. I would like to see a new event on controls called "User Control Ended".

For instance, consider a user grabbing a slider knob:

The user is able to drag the mouse anywhere, even outside the bounds of the window, and still have control of the slider:

And if the user Mouse Ups outside the window, you can't detect when that event happened. Here, Mouse Up and Mouse Leave are of no use on either the control or the pane. The new "User Control Ended" event needs to be robust like "Drag Ended", detecting events that happen even outside the VI pane.

Conclusion: when a user is interacting with controls using a drag-like operation, I need to know when the user releases the mouse button, whether it be inside the pane, outside, wherever. I have illustrated the example using a slider, but the idea I think should encompass nearly all controls (e.g., a user clicks on a Boolean with "Switch when Released" mechanical action, then drags the mouse outside the Boolean and releases to effectively cancel the Value Change event. Well, I'd still like to catch the "changed mind and released mouse button elsewhere event", a.k.a. the "User Control Ended" event)

EDIT: Attached the VI so you can play with it.

Message Edited by JackDunaway on 02-19-2010 11:24 AM

View All (8)

Restricted autoscaling

It would be nice if it was possible to restrict the autoscaling (in graphs and charts) to one direction only, and to limit its operation to a certain range. A typical use for this would be to set the scale minimum to zero - and then let the autoscaling adjust the scale maximum.

You can of course achieve this by writing your own autoscaling function, however the need for such coding could easily be eliminated by adding a few options to the already existing feature.

In addition to the directional limit and range it could have variables like a minimum step size / maximum allowable overshoot, maximum number of points off-scale etc.

Case Merger function

Every now and then I (or others) have two case or event structures that I would like to merge, either completely or just copy some cases from one to the other. If we are talking about one or a couple of cases, doing it by creating empty cases and copying the code from one structure to the other as is the option today is fine. If the number is much higher this gets quickly tedious, and we have to come up with alternative solutions.

(Making a subVI of the two and add another case structure around them, as described in the discussion linked to above, is one - but that changes the layout and adds another selection to the logic).

So how could it be handled by the IDE instead and made much easier?
A case merger function.

Here are a few quickideas on how to implement it (but any similar solution would be better than none);

Copy-Paste-Merger: Selecting the frame of structure 1, copying it, selecting frame of structure 2 and pasting will bring up a merge dialog with the following options:

a) Replace structure?
b) Merge structures (all cases)?
c) Merge selected case only into structure?

Now if the user selects to merge the whole or just the top/selected part of the structures (b or c) the function has to handle overlapping cases (just like the OS does when copying into a folder with existing content) by asking the user whether to keep the old ones, replace with the new ones or leave them as non-unique values (or add an index to the value) for the user to tidy up manually afterwards.
Drag and drop merger; identical to the previous suggestion - but instead of copy/paste the transaction is initiated by dragging structure 2 over structure 1 and e.g. holding it with an edge aligned when dropping to indicate that it is not intended to go *into* the other structure.
A merge option that can be called from the menu or contextual menus on case/event structures. The advantage of this would be the ability to add more complex mergers where you would want to pick frames x, y and z from structure 1 to merge with structure(s) 2 etc... This option could alternatively be combined with the other two and used as the dialog when those are initiated.

give decorations a property nodes

This idea is an extension / alternative for this idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/give-decorations-a-label-property-to-address-and-modify-them/idi-p/3558864

You can give Kudos to both 😉

Sometimes it's very useful to modify a front-panel decoration element programatically. E.g. moving it, changing its size, color or visability. All of those properties do already exist but it's hard to reach them (if your read the other idea, you'll see that it is even imposible for a specific element).

What I'd like to have is a right-click-menu-entry "create property node" (same for method node). The result shall be a property node appearing in the block diagram which is linked directly to the decoration element.

View All (3)

Selector Label (Case Structure)

When a Structure_Case is larger than a screen,

I scroll through the sub-diagrams with "CTRL+mouse wheel",

The problem is that the selector label is no longer visible.

The selector label should always be in the middle of the visible part of the Case structure.

like this,

View All (1)

LabVIEW Idea Exchange

Give Bookmark Manager a hotkey to open it (ctrl+k would be nice)

new primitive to deallocate unused memory from queues

Stall Data Flow should be a no-op in the event of an error

Add Increment/Decrement Buttons to Height/Width Controls in Appearance Properties

(Optionally) List events the same way when selecting as when editing

Give numeric control a radix display option of "ASCII"

Create SUB-VI from selection should intelligently inherit control names

Cluster, Right-Click, Remove Cluster like Tab Control, etc.

Resize Text (Comment or String) with Double Click

Insert class VI contextual menu

Open/Create/Replace File Function - create file's path if it does not exist

Handle activX or DotNet callbacks as events ... View callbacks in event structure !

Relative Path Node

LabVIEW should have a native popup message that doesn't hang the code

Create a "User Control Ended" Event

Restricted autoscaling

Case Merger function

give decorations a property nodes

Selector Label (Case Structure)

Allow Different Border Colors for Different Cases