LabVIEW Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
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

1.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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!

There are times when I leave a VI with modal properties open and then I run the main application that also calls this VI if opened in the development environment. This locks all running windows due to the modal VI. I propose a button in the taskbar that aborts all running VIs OR perhaps a list is opened on right-click of all running VIs 🙂

 

abort_all_running_vi.png

 

 

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).

 

dwb_0-1703104642443.png

 

Please implicitly consider array index during index / replace elements in In Place Elements Structure if I am starting from Index 0

 

Present method:
image.png

 

Expected method:
image (1).png

 

[admin edit 2021-02-24]: placed images in-line with text and removed them as attachments

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

LabVIEW's units support angular measurements of degrees, minutes, seconds, radians and steradians but I don't see support for a full revolution. If this was added, we could use 'rev/min' as a unit which is a very common unit.

 

I think that users don't really use units as much as they might because of limitations such as this. There are some other things that I would like changed with units, but this should be and easy one to fix.    

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).

 

Jim_Kring_0-1715216735950.png

 

Jim_Kring_2-1715216863669.png

 

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! 🙂

The title says it all.

In 2021 there was excitement about improvements to LVCompare and LVMerge, however there is still no way to compare classes or libraries.

I'm ok with not merging. I know that is a minefield. But at least show me what methods were added, what library or class settings were changed, which VIs moved from private to public and for classes, diff the private data and maybe show changes to the class heirarchy?

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).

 

 

Jim_Kring_0-1707938415587.png

 

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.

hiddenCode.png 

Many times a day I need to look at the full text of an error cluster's "source" string.

The workflow for this has always been awkward.

Additionally, "Explain Error" also requires some extra clicks.

 

What if we combined all of that functionality into the context help so that, when the user mouses over a populated error cluster with context help enabled, the user can see all the relevant information quickly?

 

ContextHelpErrors.png

It would be really nice if double-clicking column header separators in tables, trees, and multicolumn listboxes automatically resized the columns based on their contents (like Microsoft Excel). This would be useful in these types of controls and indicators at both edit and run time. It would also be useful to have this capability interactively (initiated by the developer or user) and programmatically (through properties or methods).

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

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

simple.png

 

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

complex.png

 

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:

links.png

  • 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

 

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: 

_carl_0-1655215157557.png

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:

_carl_1-1655216075971.png

 

(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.)

You can currently pin LabVIEW projects, VIs, and other files to the file lists in the LabVIEW start dialog as shown in the pictures below:

 

Ryan_Wright__2-1712932470451.png

Ryan_Wright__3-1712932507143.png

Ryan_Wright__4-1712932555995.png

 

It would be really nice if the Recent Projects and Recent Files menus in front panels and block diagrams automatically included the same files at the top of the menu item lists (and in the same order) as illustrated in the pictures below:

 

Ryan_Wright__5-1712933140673.png

Ryan_Wright__7-1712933697562.png

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:

 

_carl_1-1709776637528.png

 

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:

_carl_0-1719594144175.png

_carl_8-1719594621558.png

 

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

_carl_5-1719594530350.png

_carl_6-1719594541579.png

_carl_7-1719594559755.png

 

(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