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

[altenbach]

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

[Jim_Kring]

Great idea!  Until then, you can use the OpenG Fit_VI_window_to_Largest_Dec, shown below:

This utility will fit (resize and center) a VI (defined by the "VI Ref" input) about the largest decoration in that VI. It will add a border defined by border spacing in units of pixels. If there are no decorations found in the VI it is a no-op and will not produce an error. Unfortunately, this VI can not find locked decorations (yet). 

[altenbach]

Thanks Jim.

Yes, I remember this utility from many years back. 🙂

The problem is that I don't necessarily want the largest decoration, but a specific decoration. I also want the resizing to automatically revert once the VI is no longer running.

I have not tried, but how well does it work for Xcontrols? Again here I would strongly prefer a larger edit window which would automatically snap to the desired cutout when I place the Xcontrol on a front panel.

[Darren]

I would add to this idea that any controls outside the runtime viewable area not be toggled/focused when tabbing around the front panel when running.

[altenbach]

Oh yes, we definitely need a Darren analysis to fine tune the exact behavior.  😄 "Outside" object should clearly not be reachable by tabbing.

OTOH, a "return" boolean or other key assignments should be allowed to reside outside the view and still react to the keys.

[InternationAL]

On a related note, it is difficult to program LabVIEW on a high resolution setup, which you would want to do, since you've got a bazillion windows open while coding, for a setup that is lower in resolution.  On a desktop, at 1600X1200, for example, it is hard to code for a laptop that will be running at 1024X768.  Why can't I tell LabVIEW what the target resolution is, and have some guidelines pop up on the front panel?

[JB]

Darren's suggestion was the main point I thought about when I posted this idea. Obviously, it would be even better if all controls outside the visible part of the FP would be skipped while tabbing independently of a LabVIEW option.

[Matthew_Kelton]

The basic part is already available - having a seperate runtiume and edit time FP size.

In the VI Properties, Window Runtime Position, you can set the Panle Size to not be the current size.  I get it "right" then click the set to current values button.  Then I can open up the front panel and know it will always go to the size I originally designed for.  ( I only recently found this newer feature).

I usually drop a origin property to make sure the panel moves back to the origin in case I unintentionally scroll the window.  It would be ncie to have a new option to have the window shift to a sepcific panel origina at runtime automatically for you.  I do ike the idea of a visual representation of the runtime panel size.

[Baptiste_CA]

I like the ideas here - I am annoyed I have to increase the width of my FP when I want to use the Reorder / Resize Objects toolbar buttons for small front panels.

Thanks Matthew for sharing your discovery in the LV options - I will consider using this.

Some kind of visual effect like in the attachment of Altenbach would be better than the existing option (which also lacks the origin parameter). I would like an option in the View menu to display the "preview running FP area" similar to the MS-Excel page brake preview.

To add to the discussion, I'd like to mention that all could be a little bit tricky or messy when using multiple panes an plitters - you get one origin per pane for example...

[RandyP]

This is a great idea. For some reason it reminds me of the "set printable area" tool in Excel. I think there should additionally be a "debug runtime" window size option. I often want some usually hidden indicators visible when I'm debugging. It can be especially obnoxious to see them if I've turned off scrollbars at runtime.

[James_W]

Instead of using openG code, and searching for a decoration, currently I use a VI that gets the display area from a control.

It references any VI in the call chain and as long as the label of the control is hidden the Front panel is snapped to the bounds of this control (Classic - simple string) - colouring the control and it's border allows the ease of seeing the display area as altenbach suggested, and dragging it out allows it to be resized easily.

There is a small performace hit with this VI (it takes about 150-200ms to run), but it only needs to run once on each VI that is loaded.

I'm not sure my boss would let me put the code here, but it's so simple that I'm sure you're all capable of writing it in 5 mins.

An alternative option for those that want it.