LabVIEW Idea Exchange

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

Bundle automatically names cluster elements for some references but not to a VI.

dwb_1-1729527929738.png

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  

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.

Currently the fastest way to open the Properties page of a front panel element (control, indicator, decoration) is right-click >> Properties.

 

Holding down a modifier key (Alt, Ctrl, Shift, or a combination of these) while double-clicking on the front panel element would be quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Notes

  • Opening the properties page of front panel elements is a common, repetitive task, especially when creating complex UIs where the size, colours, display format, data entry limits need to be changed.
  • Ideally the gesture would work on block diagram terminals too.
  • This idea is very similar to New keyboard shortcut: Alt + double-click to open Properties in Project Explorer. The difference is that this idea addresses opening the Properties page of front panel elements, whereas that idea addresses project items.

Currently the fastest way to insert a Bundle By Name node into an existing cluster wire is to use the QuickDrop Ctrl + I shortcut.

 

Holding down a modifier key (Ctrl, Alt, Shift, or a combination of these) while double-clicking on an existing cluster wire would be even quicker.

Combined.png

 

 

 

 

 

 

 

 

 

 

Notes

  • Inserting BBN nodes is a common, repetitive action when working with clusters. For example, when working inside the Message Handling Loop of a DQMH module.
  • The gesture should work for class wires too, but only if access scope rules allow it.
  • This idea is very much related to the "New gesture to create Unbundle By Name node (Ctrl + double-click when creating a cluster wire branch)". The difference is that this idea addresses inserting BBN nodes into existing wires. That idea addresses more easily terminating a new wire branch with a UBN or BBN node.

Thanks

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

When you develop with multiple LabVIEW versions, it is sometimes difficult to identify which version you're using or launching based on the icon of the LabVIEW EXE:

 

taskbar.png

 

Here's my Windows 7 taskbar with, among other things, LabVIEW 8.0, 8.5, 8.6, and 2009 icons.  Which one is which?  There are ways to tell, but it sure would be easiest if the version number were overlayed on the icon.  Note the Visual Studio 9.0 icon in the taskbar...I think we should do something very similar with the application icons of future LabVIEW releases.

 

NOTE: The icon should also reflect differences between the 32-bit version of LabVIEW and the 64-bit version of LabVIEW

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.

Many of us using graphical programming for scientific applications, where we dealing with numbers, measurements, etc.

How often we grab to Windows Calculator to compute simple equations?

What about ability to enter something like 3,75*2,8 into any constant or control (in principle everywhere where we can put numbers) and then get computation result in this place:

Screenshot 2024-03-06 09.16.22.png

In the past I've worked in desktop publishing industry and using the software called "Macromedia Freehand MX", and that was really "killer feature", which saves huge amount of time.

 

This is how it works:

resize.gif

Or for example, 5 rotated copies:

rotate.gif

Even in Color mixer simple computations are allowed:

mixer.gif

Everywhere where I can put some numbers, in any dialog:

guides.gif

So, my suggestion to have the same in every numeric control or constant.

 

This is what I mean:

numeric1.gif

So, it should be allowed to enter here something like "3*5" or "42+3*5" 

As MVP suggested to have the only (at least) base operations *, /, +, -, also combined as shown above, but may be "advanced" support (like fully offered by Formula String) is also not so bad, why not:

numeric2.gif

Anyway it should work everywhere, including constants on the Block Diagrams:

numeric3.gif

Also, for example, on Resize Objects Dialog:

Screenshot 2024-03-06 11.20.04.png

Or even in the Settings (in general everywhere for any numeric field across whole LabVIEW):

options.png

 

And also in Run-Time, of course, not only in Development Environment.

 

If you think that "always enabled" feature will be annoying, then I can suggest to make this optionally per Control/Constant Option:

Screenshot 2024-03-06 11.31.54.png

Or may be as global setting in the Options.

The "Probe Display" pane of most default probes should have indicators that are set to "Fit to Pane". The worst offenders, in my opinion, are Strings and Variants...I often find myself cursing the fact that I can't see more of the data, and usually have to copy & paste into Notepad++ or something to actually see what I'm looking for.

 

Yes, you can make custom probes for this behavior. But it should be native.

 

probe.png

When a 1 Dimensional array of any type is showing only a single element, LabVIEW forces a horizontal scrollbar. I couldn't find any documentation or reasoning behind it. It's really annoying and ruins UI design that Vertical is the normal scrolling direction for just about everything else ever and LV messes that up for some seemingly arbitrary reason.

I think structures should have a better label system. Currently I use free labels of the same color as the loop which looks great and makes the code easy to read and debug. But if I resize my loop I have to manually resize the label as well. I think this should be built into a right-click option.

 

(structure) rick-click » visible items » Structure label

 

Integrated Structure Labels.PNG

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.

Edited Image 1.png

Notes

  • Replacing a node via Right-click >> Replace >> selecting item from palette results in the same outcome as replacing via QuickDrop. This idea should apply to both replacement methods.
  • Replacing a VI via either QuickDrop or right-click behaves correctly. The new VI label is visible only if the old VI's label was visible. In effect, the new VI retains the "Label >> Visible" setting of the VI that was replaced, which is desirable.
  • This idea is somewhat related to the following idea: "Show node names when dropped" option

Idea:

 

So my idea is to add an optional parameter "ObjectRef" to both GObject methods "Replace" and "Replace No Attributes":

raphschru_0-1732660843348.png

My request is mostly for replacing a control or a constant, but the proposed formalism could also work to replace any Node (SubVI, Structure, ...), a Diagram, a Panel, a Pane... by copying the properties and content of an existing one in memory.

 

 

Reasons:

 

Often in my scripting, I need to replace a control or a constant by copying an existing one. Most of the time, this is to change its data type, but also sometimes its style.

 

The current GObject methods "Replace" and "Replace No Attributes" are very handy to replace a control or a constant while maintaining their links to the other objects on the diagram, provided that you have the path to an existing (saved) .ctl file to give as a parameter to the method.

 

If the data type is not a type definition or is an unsaved type definition, things get complicated. This can happen and I don't have control over the data types passed to my tool.

 

To achieve this, I found 2 techniques:

 

1. Replace by a temporary Control file:

  - Create a new VI of type "Control VI";

  - Drop a new control using VI methods "Create from Data Type" or "Create from Reference";

  - Save the .ctl file to a temporary path;

  - Use method GObject.Replace with parameter "Path" on the old control / constant .

 

This works in most cases except when the data type contains out-of-scope typedefs. I can then work around this by disconnecting the typedefs and replacing sub-elements by path as a post-process, unless some typedefs are not saved by the user...

 

2. Recode the Replace method from scratch:

  - Drop a new control / constant using VI methods "Create from Data Type" or "Create from Reference";

  - Copy all relevant properties from the old control / constant to the new one;

  - Reconnected its terminal to the wire on the block diagram if needed;

  - For a control, relink locals, linked properties nodes, linked method nodes, references;

  - For a control, reassign it to the connector pane if needed...

  - ...

  - Delete the old control / constant.

 

This is a lot of work, seems quite inefficient and also is not future proof in case new properties are added to controls.

 

 

Regards,

Raphaël.

I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).

PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.

 

As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.

 

I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.

 

There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.

 

The solution could be as "simple" as this:

  • When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
    • Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
      • Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
    • When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.

Currently, the block diagram has an endlessly useful feature. I use it every day - the Distribute Tool.

 

FrontPanelSpacingTool.png 

 

 

The following feature would be AWESOME for expediting BD readability:

 

BlockDiagramSpacingTool.png

I started a discussion here

 

Although the suggestion about using a template is quite nice, I would still like to be able to create a new VI (or sub-VI) from within a project.  I never use the default icon provided by NI.  -- N-E-V-E-R --   That's a personal choice. 

 

So since I never use that icon, the fact that creating a new VI which auto-generates an icon that is never used, renders that feature useless.  Let's see how many users of LabVIEW also find the default icon useless....  (Kudos would be a way to take a poll).

 

A nice feature would be to allow the developer to create her / her own default icon.  The default icon is probably somewhere in the ini file (I have not checked).  One of the Options could be to select if the user wants to use their own default, and if so, browse to the icon or have an editor create one.

 

In my case, when creating a new VI, it ends up with a icon like this:

 

 

 

I would be happy to have a default icon that looks like this:

 

 

 

The idea I am proposing is that developers should be able to have the icon of their choice as a default icon.

 

And may plenty of kudos adorn this thread..  🙂

 

Spoiler
 

 

I don't like the way that long file paths are shown in path controls and indicators:  If the path is longer than the textbox (and it usually is!), the user only sees the first several levels that fit.  This can be pretty confusing.

 

One way to solve this issue is to truncate the path in the middle in such a way that the filename or last folder (which is usually what's most important) is always shown.  I've seen this in other UIs and it should be a natural thing for users to understand.

 

Here's an illustration:

truncate_path_ctrl.png 

 

I think this should be a built in feature of the path controls and indicators, accessible through right-click menus and/or the properties menu of the control at edit time.