LabVIEW Idea Exchange

Top Authors

User

Kudos

Post an idea

The Project Explorer Files view already contains the useful "Move on Disk..." option. It would be useful if, when a VI or CTL is owned by a lvclass or lvlib, an option named "Move to Owner Folder" (or similar) existed. This option would move the selected file to the folder that contains the lvclass or lvlib that owns that file. This action would be equivalent to using the "Move on Disk..." option, but would save the user from navigating the (potentially large) folder structure to find the right folder. In short, it would save a few seconds and would help ensure consistency. It would also encourage the best practice of storing owned VIs and CTLs in the same folder as their owner lvlib or lvclass (actions that are easy to do are performed more often).

For example

Screenshot 1: A project that contains two libraries

Screenshot 2: In the Items view, the mouse was used to drag C.vi from Library 1.lvlib to Library 2.lvlib

2 (edited).png

Screenshot 3: Typically, I would now press Ctrl + E to switch to the Files view, right-click the file, and select "Move on Disk...".

3 (edited).png

Notes

It would be great if the "Move to Owner Folder" menu item was also available when multiple items that are owned by the same owner are selected.
A related idea: It would be useful if, when using the Items view to move an item from an owner to another, LabVIEW would pop up a dialogue message similar to the following "Would you also like to move the file on disk to folder <insert here the folder path of the new owner>?". The dialogue would contain Yes and No buttons. This would save the user from having to switch to the Files view altogether.

Thanks!

View All (1)

View All (7)

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-than/idi-p/2299860). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-window/idi-p/1844127).

View All (3)

It's not uncommon to accidentally leave a process hanging and to have a really hard time tracking it down. Different folks seem to have made different "kill all VI" tools, but this should be a native LabVIEW feature supported by NI. The tool should just work. "Ctrl+." doesn't always work. You should be able to push some shortcut that works even if you have a frozen modal dialog or whatever, and all running VIs are stopped, and log of which ones were stopped prints to the screen.

Excel displays the number of selected cells.

1 (edited).png

VS Code displays the number of selected characters.

5 (edited).png

LabVIEW should display the number of selected items in the Project Explorer.

2 (edited).png

LabVIEW should also display the number of selected items on the block diagram and the front panel.

4 (edited).png

Notes

In the Project Explorer the functionality would be useful to count/monitor/audit the number of VIs and CTLs in a lvclass, lvlib, or in a virtual folder of these owners, etc. It would be nice to know at a glance "oh, there are 12 public VIs in this class".
The block diagram count functionality can become more useful in large projects and VIs. For example, I recently edited the block diagram of a VI in a DQMH-based project. The project contains 16 DQMH modules at the moment (more to be added). I wanted to check that the VI I was editing was calling the Start Module.vi public VI of each of the 16 modules (wanted to check that the VI would launch all DQMH modules). The only way to do this was to "manually" count the VIs on the block diagram. Selecting them and LabVIEW displaying "Count: 16" would have been easier.
In the block diagram the information displayed by LabVIEW could be more nuanced. For example, it could display the total number of items selected (subVIs, nodes, property nodes, etc), but also a breakdown based on item type: number of VIs, number of nodes, number of property nodes, etc. All these selection stats may occupy too much space for all to be displayed at once. Perhaps they could be displayed in an element that, when clicked, expands to present all the information.
The block diagram and front panel count functionality would enable programmers to quickly estimate the complexity of a VI. Pressing Ctrl + A on a block diagram to select all items, then looking at the selection stats would reveal the relative complexity of that VI.
If a whole structure is selected on the block diagram, then the count should return the count of all items contained in the diagram, not just the items displayed to the user. For example, if a case structure is selected, the number of items contained in all cases should be displayed.

Thanks

View All (3)

Add Revolution Unit

Right now, there's no way to easily open show a LabVIEW project file in the "native operating system file explorer" on Linux (for me on Ubuntu, that's the the Gnome "Files" Nautilus app and I can easily open a folder from a terminal/shell by executing an `open .` command).

Side Note: In VS Code (as described in the documentation), you can open to the location of a file or folder in the native operating system file explorer by right-clicking on a file or folder and selecting Reveal in File Explorer on Windows, Reveal in Finder on macOS, or Open Containing Folder on Linux.

Let's please add this to LabVIEW for Linux! 🙂

View All (1)

LVCompare for Classes and Libraries

Currently, the TDMS File api does not offer a way to get the TDMS file size.

Our use case is that we'd like to limit the size of the TDMS files and span them accross multiple individual files (and I've posted an idea suggestion for adding that as a native feature, too). To do this, we need to be able to monitor the TDMS file size, so that we can save/close the current file and then create the next file in the span for continued use (until we hit the size limit again).

View All (1)

Preamble:

Just following up on a sub-idea raised within this recent idea from tst: LabVIEW should break VIs which have hidden code. I *almost* like tst's idea, but IMO it is a bit too heavy-handed:

YES, I want better information when there is hidden code on my diagram, but...
NO, I don't want my code to break!

The Idea:

If a structure hides code beyound it's boundary, then provide a visual indication. For example, the edge of the structure could be coloured red to alert the user that something unexpected is going on.

View All (5)

View All (4)

It can be difficult to go back to the Search Results window when searching for subVIs or text in a project with many open VIs.

It'd be great if the Search Results window had an "Always on top?" option. The screenshot below shows a possible implementation, using a tickbox.

1 (edited).png

I'd be happy for the default value of the tickbox to be false (unticked). The default behaviour would be identical to the current behaviour.

When the option is ticked the Search Results window would float on top of other VI windows, similar to how the Probe window floats on top.

This would make life easier when going back and forth between a few results, with many VIs already open, especially when so many VIs are open that all LabVIEW windows have collapsed into one tall list in the Windows taskbar.

This feature is not terribly impactful, but has a high benefit-to-effort ratio, due to the very small implementation effort.

Thanks

View All (2)

In a simple project, the main entry point into an application is usually easy to find:

However, for more complex projects (particularly those utilising libraries/classes) it may not be obvious where to begin:

Proposal:

LabVIEW should provide a mechanism for tagging one or more VIs such that they are easily accessible to someone unfamiliar with the project.

One possible implementation:

Display tagged items as links at the top-level of the project.
Links would be pinned to the top row
Link names would be editable and need not correspond to the name of the item they link to. (e.g. The link "main" may point to "WidgetTester.lvlib:GUI.lvclass:launcher.vi")
For minimal confusion, developers should be encouraged to name the first link "main" (or similar)
In principle links could point to anything interesting, not just the main VI.
Double-clicking a link should open (or navigate to?) the target item

View All (4)

LabVIEW 2021 now has this pop-up, which lets you know if you still have VIs running in the background when you try to close a project:

Great! Because previously you were alerted that some VIs were still running, but not which ones. So this helps substantially with debugging.

However, I usually just want to abort these VIs without closing my project. There's still no (obvious) way to either open or abort these still-running VIs. That leaves me twiddling my thumbs (often for several minutes on large projects) while I close and re-open the project.

The request: Add the ability to either open or abort these running VIs from this window. It could be as simple as adding an "Abort All" button...or even adding documentation on how these could be closed:

(And yes, obviously the correct solution here is for me as the developer to fix the bug that's leaving these VIs running... however, in the real world, sometimes this is either lower priority than other issues, or falls onto someone else's plate...and in the meantime you're left regularly waiting for your project to reload.)

View All (8)

When refactoring code, I often find myself in a situation where I've broken dependencies. Maybe it's a name change, or a library path change. This is precisely when I'm most in need of the ability to just replace the missing file (be it a VI, control, class, or PPL). Yet this is when LabVIEW decides that nope, it can't be that easy:

Instead you have to track down every instance and manually swap them out.

The request: allow us to replace missing files using the "Replace with..." option.

If I have a standard VI that's hung, I can highlight execution, and then drill into the hung VI (reentrant or not) to see what's going on:

But...if it's a class override method, I can't do this:

(There is technically an exception: If the override is not reentrant, and you guess the correct override in the popup, then you can debug it.)

This experience would be so much better if I could drill into the overrides seamlessly, without being prompted for which override to look at, and with the correct runtime instance of the override popping up. This is the kind of thing where, on complex projects, this improved debugging could literally save me hours on some bugs.

In Windows File Explorer, Alt + double-click on a file or folder pops up that item's Properties page. It is equivalent to right-clicking and selecting Properties. This is a useful, time-saving keyboard shortcut/gesture.

The same keyboard shortcut/gesture should work in the Project Explorer. Executing the shortcut would pop up the Properties window of whichever item was double-clicked on.

The shortcut should work for lvclass and lvlib items, VIs, and CTLs (and possibly other item types too). For lvclass and lvlib items the Properties window would appear. For VIs and CTLs the VI Properties window would appear (equivalent to Ctrl + I).

Screenshot 1

1 (edited).png

Screenshot 2

2 (edited).png

Thanks

View All (4)

LabVIEW Idea Exchange

Project Explorer "Move to Owner Folder" option in Files view

Abort all VIs Button in Taskbar (Modal Windows Problem)

Indicate that array constant contains more elements than currently visible with scroll bar

Implicit consideration for Index in In Place Element Structure

Include foolproof shortcut to stop all running VIs and report which VIs were shut down

LabVIEW should display the number of selected items in Project Explorer, block diagram, and front panel

Add Revolution Unit

[Linux] LabVIEW Project Environment missing "Explore..." option (to show the file in the OS's native file explorer)

LVCompare for Classes and Libraries

Need a way to get TDMS File Size from a TDMS File Reference

Visual indication that a structure is hiding code beyond its boundary

Detailed Error Info at a Glance in Context Help

Double-clicking column header separators in tables, trees, and multicolumn listboxes should automatically resize the columns based on their contents.

"Always On Top" option for Search Results window

Project should support links (like bookmarks) to main VI

Add ability to open/abort running VIs from "Abort Running VIs" popup.

Include files pinned in LabVIEW start dialog in front panel and block diagram Recent Projects and Recent Files menu item lists.

Enable "Replace with..." when dependency not found in project.

Drill-down debug capabilities for class overrides

New keyboard shortcut: Alt + double-click to open Properties in Project Explorer (similar to Windows File Explorer gesture)