LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
altenbach

Unused items tray

Status: New

Re-opening because LabVIEW NXG has been discontinued.

Important disclaimer: I am sorry, this is not my original idea, because it is (together with many other nice features!) already implemented in the LabVIEW UI builder. Credits go to the relevant NI developers.

 

This Idea posted here tries to see how much interest there is in such a feature and to show support that we want this also implemented in plain old LabVIEW. Personally, I really like it! 🙂

 

(It is also somewhat related to this idea (but probably not a true duplicate), especially my comment there already exapands on the idea!)

 

The Unused Items Tray (see also e.g. Christina's Blog entry) is an area on the diagram that contains terminals or FP objects that have not yet been manually placed or are currently only "used" on the BD "xor" FP, i.e. not on both.

 

The current problem in LabVIEW is that if you place a new control on a complicated VI, the terminal will end up on some random place, typically piled well camouflaged on top of some other diagram structures and possible a scroll away from where it is actually needed. Similarly, if we create a control or indicator from a terminal on the diagram, the control will typically be outside the carefully placed visible area and there is no way to grab it without first messing up the FP alignment by either scrolling or enlarging the window.

 

In all these cases, it would be nice if the objects on the "other" window would land in a predictable reserved floating location for quick and easy manual placement where they belong. During development, there are probably a few terminals that are not yet used or connected, and we should be able to place them back into the unused items tray of the diagram so they never scroll out of view or get misplaced.

 

On the front panel, we might have some spare controls "parked", and they would not show in run mode at all. This could even be abused for "local variable zombies" (=hidden controls with the sole purpose of making a local variable) along these lines, which might be OK (=better than hidden controls!). Front panel items in this tray would look like their palette entries. We don't want e.g. full-sized graphs in there!

 

Now, how should all this look like? In order not to cover valuable diagram space, it should be something that collapses to near nothing when not used and would only expand to show the current contents when hovering or clicking in a special area. Of course there should also be an option to pin it open. When minimized, it should look different when "not empty" vs. "empty".

 

10 Comments
X.
Trusted Enthusiast
Trusted Enthusiast

Nothing is more infuriating when creating a control (or indicator) from the diagram than to have to double-click on the terminal to have find the control on the panel and get the pixel-precise panel boundary adjustment thrown away in the process (think multiple pane panel for instance or precisely adjusted tab size).

As mentioned by others, a real good scheme is that used by the LabVIEW WebUI builder. Another possibility would be to have a right-click menu contextual menu option to define the location of the new control (near last created control, panel center or corners, ...).

altenbach
Knight of NI

> ... double-click on the terminal to have find the control on the panel and get the pixel-precise panel boundary adjustment thrown away ...

 

Of course that problem is specifically addressed by this idea. 😄

 

(Your pixel-precise boundaried are curretly also doomed if the window is very small (e.g. for an xcontrol facade) and you need e.g. access to the alignment tools in the toolbar. :()

X.
Trusted Enthusiast
Trusted Enthusiast

...which is of course an issue that was discussed here Smiley Very Happy

KeithTK
Member

As an alternative, could the behavior of labview be changed to something like this:

Once a new control is first dropped on the front panel the window focus is shifted to the block diagram and the terminal for that control is automatically put into the "picked up" state the same manner as when a new property node is created from the right-click menu.  The next click from the user drops the item following the usual placement rules.

Optionally (set in user preferences) the window focus automatically returns to the front panel.

 

The same would be true going from the BD to FP such as a right-click->create->control action, forcing the user to place the control on the front panel themselves.

 

This way both the FP and BD locations of every item are determined by the user.  It adds one click to the placement operation and lets the user maintain any layout method they desire.  This behavior would be default, but could be reverted to the old behavior in the user preferences.

 

In general the right-click->create->control/indicator should be placed with another click the same way as a new local variable or property is done now.  Currently it puts the new terminal right next to the location it is wired to.  This feels non-standard as other right-click generated items are auto-grabbed.

 

RavensFan
Knight of NI

Keith, that is a nice idea.  But not the behavior I would want all the time.  If I'm adding 1 new control in a mostly developed VI, that would be fine.  Sometimes I am just working on a Front Panel layout, and I want the focus to stay with the front panel while doing that.  The switch to the block diagram would be a huge distraction.  I would rather have the terminals placed somewhere safe, (and if I've done no wiring yet, the middle of the block diagram would not be an issue) and I'll deal with the terminals later.

KeithTK
Member

I agree, during the initial buildup of a new front panel, dropping every terminal would be tedious. 

 

Perhaps an enable/disable for this behavior in the edit menu so that on a new VI, "auto-place terminals" is enabled and behavior is as you described.  After the initial front panel layout, users could disable "auto-place terminals" and the double-window-drop behavior would take over. 

 

The setting should be saved with each VI to prevent auto-placement taking over since no one will remember to disable it every time a VI is opened.  Or the setting could default to enabled for new VI and disabled when opening an existing VI.

GregSands
Active Participant

Over here I've suggested something similar to this idea, and Keith's proposals too, though it suggests a Block Diagram-centred view of programming. 

Yamaeda
Proven Zealot

A version of this idea would be to place all indicators on the right of the diagram and all controls on the left, where they'd be placed of doing a automatic cleanup.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Darren
Proven Zealot
Status changed to: Completed

Available in LabVIEW NXG. All new controls and indicators on the front panel are placed in the Unplaced Items Tray. A similar approach is taken for control and indicator terminals on the block diagram.

Christina_R
Active Participant
Status changed to: New

Re-opening because LabVIEW NXG has been discontinued.


Christina Rogers
Principal Product Owner, LabVIEW R&D