LabVIEW Idea Exchange

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

We need to uncouple the "edit mode" FP size from the "run mode" FP size

Status: Completed

Available in LabVIEW 2019 and later. Go to VI Properties > Window Run-Time Position, change the Position value to 'Custom' or 'Centered', uncheck 'Use Current Panel Size', specify the panel size you want, and check 'Scroll panes to origin at run time'. After making these property changes, a gray rectangle will appear on the front panel showing the area that will be displayed at run-time.

Resizing the front panel so it is correct when running the VI is still very tedious and can easily mess up during editing. The problem is even more severe for Xcontrols, because their runtime size is often very small so there is not even enough room to e.g. display all the tools in the tool bar during editing. Once the runtime size is correctly set, all it needs is a double-click on a terminal that has its FP item hidden outside the visible area and everything on the FP shifts and messes up.

 

We need three things:

  1. An "edit time" FP size that is "comfortably big" so we can see the entire toolbar and possibly also helper controls and even maybe some comment text intended for the programmer that are outside the operator area and only used for debugging and such.
  2. A "run time" FP size that matches exactly what the operator sees during running.
  3. A special decoration or other visual cue during editing that indicates the FP area that will be visible at runtime.

 We already have the crosshair in the upper left corner when showing the grid, so that could be defined as the upper left corner at runtime by default. All we need is define the upper left and lower right corner and the runtime FP area is uniquely defined. As a visual cue, everything outside the runtime area could be a shade darker or tinted differently than normal to indicate that fact. Running the VI would snap the FP boundaries to the bright area.

 

Then we also need handles to move any of the boundaries at single pixel increments. A control that scales with the front panel would simply scale to the bright area instead. Of course a legacy mode for older VIs that did not have this feature during their creation needs also to be supported.

 

The example image shows a reddish transparent area (just to throw out another idea, maybe a slightly darker grey would be better). This is one of my own subVIs that demonstrates the problem at hand. At runtime, only the progress bar should be visible, while at edit time, I want to see all controls, because I might need them e.g. to wire the connectors. It is not easy to switch between the two sizes.

 

(Of course we can currently program around all that by setting windows parameters via property nodes, but it is ugly, inefficient, and tedious.)

 

 

 

22 Comments
Yakov
Member

I think that we need three different views/layers for a vi:

1. user interface/front panel

2. data layer

3. block diagram

 

I don't need all internal data to be on front panel.

I don't need all those bulky 3d effects of user interface to represent my internal data.

I don't need to mess up my user interface just to change something in my internal data.

 

SteenSchmidt
Trusted Enthusiast

@Yakov: You don't need a data layer, as you shouldn't use the front panel for data transfer. Keep strict data transfer in the code at all times, and use the FP for UI only. The only exception is if you use the FP for VI Server data interface, but that's an exception.

 

I came across a guy the other day that tried to convince me that using the Value (Signaling) property of a control was faster than generating a proper user event to his consumer event structure(!). That's just wrong on so many levels...

 

Cheers,

Steen

CLA, CTA, CLED & LabVIEW Champion
cwolfskill
Member

It would also be nice if this area could be set as the maximum window size, such that you could allow users to resize the window and if it were smaller than this size, scrollbars would show, that only allowed them to scrol to see this designated area.

JW-JnJ
Active Participant

Rather than seperate runtime and front panel environments, how about a new placeable object? A box that defines the runtime area.

New Bitmap Image.jpg

Josh
Software is never really finished, it's just an acceptable level of broken
altenbach
Knight of NI

> Rather than seperate runtime and front panel environments, how about a new placeable object? A box that defines the runtime area.

 

You might want to read my suggestion again. That is basically my suggestion already. Except for some minor cosmetic differences, your image is an exact duplicate of my original image. I never suggested seperate "environments", whatever that means.

 

JKSH
Active Participant

Kudos kudos kudos.

 

To flesh this out some more: The "Fit Control to Pane" or "Scale Object with Pane" options should use the Run-time boundaries, not the Edit-time boundaries.

Certified LabVIEW Developer
Sam_Sharp
Trusted Enthusiast

For the sake of completeness, I've posted a similar idea about ensuring the toolbar menu items and buttons are always accessible regardless of the window size here. I still think this is a great idea for UI dialogs though.


LabVIEW Champion, CLA, CLED, CTD
(blog)
EricR
Active Participant

It turns out I don't yet have the ability to set the status of Idea Exchange postings but this idea is "In Development".  As soon as I can actually change the status, I will post the outline for what we are implementing.  As soon as we can demo the functionality, it will be added to the next beta drop.

Eric Reffett | Director, Product Management | 1.512.683.8165 | ni.com
EricR
Active Participant
Status changed to: In Development

As we are implementing it, the feature will have the following user stories satisfied:

  1. As an application developer, I want to see the area of my VI panel that will be within the bounds of my window when the VI runs so that I can position my widgets correctly inside this space.
  2. As an application developer, I want to configure the initial scroll position of my panel so that I can change that scroll position while editing without affecting my runtime layout.
  3. As an application developer, I want to have widgets visible at my edit time panel that automatically hide when the VI runs so that I can configure those widgets at edit time easily without affecting my runtime layout.
  4. As an application developer, I want an easy way to configure the origin of my panel to the top-left corner of my run-time view so that I can write simpler positioning code.

 

We will not be addressing multi-pane configurations, except for the "origin" user story identified in #4.  I will post examples of functionality being added as soon as the features have passed review.

Eric Reffett | Director, Product Management | 1.512.683.8165 | ni.com
wiebe@CARYA
Knight of NI

1. As an application developer, I want to see the area of my VI panel that will be within the bounds of my window when the VI runs so that I can position my widgets correctly inside this space.

 

Just curious how NXG will do that... FPs are often full screen!