LabVIEW Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

 I believe the number and age of "New" ideas on this exchange renders the word meaningless. I just Kudoed an idea that was 13 years old and marked as "Status: New". This idea would be in middle school; that doesn't sound particularly new. Inaction on an idea after some amount of time should automatically trigger some other status. 

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

The help page, that is supposed to provide a starting point for the developers on creating readable, high quality code in LabVIEW seems to be unchanged for quite some time: LabVIEW Style Checklist - NI.

At different workplaces (including NI) and different teams I have seen different implementations of such guides, many of which included extra "rules".

One such example is the file naming convention:

  • Using spaces for separating words.
  • Using Libraries to namespace VIs instead of including the noun in every related VI.

These are the most prominent examples I can come up with from the top of my head, but I'm sure that there are more.

 

I'm curious if an updated version exists somewhere that could be used to replace the above refenced help page?

If there is not, then I think could we collect some ideas here for updating this document.

Hi guys,

I'm missing some very fast way how to create cluster out of selection. It could be done as it is shown here:

 

create cluster.png

 

I think since LV developers became familiar with Every GUI Programmer's Dream they are ready for the next step...

Currently, it's a crapshoot when you drag an ant trail selection box around items on your FP or BD. It's truly an art to become good at selecting objects in LabVIEW - we all learn "hot spots" to place our selection rectangles, and we all heavily rely on the "Shift+Click" method of adding or removing objects from our selection. Below is an example of what actually might be selected when dragging a selection box:

 

SelectionBehaviorCrapshoot.png

 

All horizontal wires were selected down to "ABCDEF", even though just a very small portion of the visible wire was inside the selection box. It's not intuitive to try to not select wire that is hidden behind the Unbundle.

 

I propose a method that mimics selection in some graphics editing and CAD programs: the idea of "Enclosed" and "Inclusive" selections. An Enclosed selection is made by dragging the mouse from L to R. This operation selects only the objects THAT ARE COMPLETELY ENCLOSED by the selection box, ignoring objects that are partially outside the selection (the red arrow is not part of the BD, it merely represents the motion of the cursor):

 

SelectionBehaviorEnclosed.png

 

Alternatively, if you drag your mouse from RIGHT to LEFT for a selection box, you select every single object that is fully or even partially contained within the selection box:

 

SelectionBehaviorInclusive.png

 

Voila! Selection is now a TAUGHT SCIENCE instead of a LEARNED ART!

Perhaps my most obscure suggestion...

 

You can't create a build spec with the same name as an existing one regardless of capitalization:

avogadro5_0-1734658840776.png

 

But if you use a mismatched case in "<vi.lib>\AppBuilder\AB_API_Simple\Build (path).vi" you get this error:

avogadro5_1-1734658933762.png

 

So either you should be allowed to create build specs with the same letters and different capitalization, or the API should be smart enough to find the matching build spec regardless of capitalization.

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

 

Currently if you right click on a subVI from the block diagram and choose properties, it brings up the Object Properties dialog.  The only options you can change there are label options, which can easily be changed in the "Visible Items" submenu.  I can't think of one time when this has ever been what I wanted out of this action.  Instead, I think this action should open up the VI Properties Window for the VI.  

 

properties1.png

The Project page of the Project Properties window contains the Mark Existing Items... button. When pressed, this button enables the programmer to enable the "Separate Compiled Code" setting for all files in the project. This is very useful.

 

Suggestion: It would be useful to have similar functionality that could enable or disable Automatic Error Handling for all VIs in the project. This could be achieved by adding a drop-down menu that enables the programmer to select whether they want AEH to be enabled or disabled, alongside a button that enables the programmer to apply the selection for all project items, as seen below.

Screenshot (annotated).png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • It may be best to add the button and drop-down menu in a new dedicated Category page named perhaps "Error Handling".
  • It would be useful to have the functionality available at a class and library level too. Meaning the ability to easily enable/disable the setting for the VIs inside a lvclass or lvlib, but not for the rest of the project.
  • The "Separate Compiled Code" and Automatic Error Handling settings are similar in that they are both Boolean settings (True/False value) that apply to each and every VI.

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

The size of the Close Reference VI makes it impossible to draw a proper block diagram.

d.png

 

It is too big!  It does not match with the Property Node vi.

 

Therefore I would propose: --> Make the Close Reference VI smaller!

 

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 

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

When selecting a set of object that are from the same class, I'd like to be able to change some of their main properties at once from the right click menu.

For instance, when selecting a bunch of numeric controls, being able to change all their representation to U8 without having to open the property page (which sometimes take some time to load.

This could be done either via the r.click option, or even via the properties page that would show that it is for more than 1 item. Via the property page 

VinnyAstro_0-1705567415946.png

 

From the property page, it would be nice to have the possibility to easily change their label and caption independently and faster (using tab) than to have to change them manually by double clinking on the labels, hoping to not click on the side of the box.

 

This happens to me all the time:

VinnyAstro_1-1705568287315.png

This could be a viable option in my opinion (Please excuse my poor designer capabilities):

VinnyAstro_2-1705569130610.pngVinnyAstro_4-1705569195313.png

 

 

 - Vincent.

The title says it all: The property dialog of controls should allow inspecting and changing the default value.

 

Here's how it could look like.

 

 

Sometimes I wand to re-define a default value without actually changing the current value.

 

current steps

  • copy the current value elsewhere
  • enter the desired default value
  • right-click...data operations...make current value default
  • restore the original value (could lose data in case of DBL!)

After implementing the idea

  • right-click...properties...enter default value...OK.

 

 

 

The VI Properties window allows to select between local help file and Web-based Help URL.

 

Loc_fr_0-1718700568074.png

 

LabVIEW Class, Library and Project doesn't allow to use Web-based URL.

 

Loc_fr_1-1718700590702.png

 

Loc_fr_2-1718700613471.png

 

The idea is to have the same behavior for all source file.

In some cases the list of context menu items extends beyond the vertical screen height (for example when creating a property for a control). The only way to scroll up or down this list using the mouse is by hovering over the small arrows at the top and bottom (and quickly moving the mouse away to stop scrolling).

 

mouse_wheel_scroll.png

 

This idea is to enable mouse wheel scrolling on context menus where the list of items is scrollable (the scroll arrows are visible) and the mouse pointer is hovering over the list. This allows for precise scrolling with much fewer mouse movements.

If you are not using the Data Event Terminals in an Event Structure, you might customarily hide them - roll them up so that only one terminal is showing. I would like to hide that remaining terminal. The idea is to not grey-out the Remove Element option when you are down to one terminal. That way, you can remove it. A stub remains to right-click on in order to bring the terminal(s) back if required.

 

24498iD9D667DE43F77BE8  

See the picture below for an example of (what I consider to be) a frustrating "feature".

Why delete the elements? Keep the elements and the element style types as is, just convert my cluster to the new style type.

Arrays also do this, but since we tend to spend more time designing clusters, it's far more frustrating than arrays.

 

 

 

ClusterReplace.png

My idea is to have LabVIEW cease and desist it's self-important modal behavior.  Not that I think LabVIEW is anything other than the most important application I run, but I don't think it should force its (many windows') way to the front of the line when I shift focus to a LabVIEW window.  I didn't find any other idea that matched this, but there is this discussion that covers the notion well.

 

An example case:  When chasing efficiency I frequently have Task Manager open to observe CPU usage when I change front panel controls.  I'll run the .vi and load Task Manager, but when I click on a front panel control ALL the LabVIEW windows come to the front and cover Task Manager:Modal.png

 

So, my suggestion is to have only the selected LabVIEW window come to the front.  I get the impression that Ctrl-Tab and Ctrl-e behavior are why LabVIEW controls its own window z-placement, but leaving their function out of it, my suggestion is just to change the modal behavior of LabVIEW windows.