Resizing/scaling a front panel including a 'slide' control (thermometer)

[cbutcher]

So I've created a VI that has some interface to a cooling unit. The VI is not too terrible looking (opinions may vary) provided it remains the size it was created at.

I have made it such that I can place this VI in a subpanel, and then use it in whichever implementation of my project I have. The subpanel can conceivably be resized, so I wrote some code to resize this 'CoolerUnit.vi'. 

Although the resizing code still needs some tweaking of values to prevent overlapping when small (minimum size is an alternative here) or horribly bloated controls/indicators when large (maximums a possibility!) there are two elements which refuse to behave nicely.

The VISA Control (COM port) label often ends up in the wrong place after resizing, and the Thermometer (which I think is of type Slide) just looks terrible - if the width increases it expands but the border around it remains fairly constant, the digital display seems tricky to move/control and the label never ends up anywhere useful.

Is there a simple-ish solution to either of these, or should I just a) manually replace the label each resize for the VISA control and b) change the thermometer to something simpler, like a numeric indicator?

I attach a simplified version of the project which should contain all of the resizing and position calculation VIs, but none of the class or internal workings of the cooler. All external dependencies should be satisfied by vi.lib.

A test VI, titled TestResize_All.vi can be run to display the problems when resizing.

[Norbert_B]

You should work with splitter bars and select "Scale Object with Pane" for resizable controls. This will reduce implementation overhead while keeping specific items (e.g. string elements) at a fixed size.

Adding code for resizing is recommended if resize should only work in one dimension (e.g. only resize horizontal even if pane is resized in vertical as well).

[cbutcher]

Although my first attempt to provide resizing support was to use splitter bars, I found this caused problems displaying the 'ErrString' and 'ErrButton' indicator/control (along with an accompanying decoration) because the would cover multiple panes, and would only draw in the pane to which they belonged.

Is there a reason that I should want string elements (or similar 'specific items') not to resize? In this case, it isn't really here or there, since the text contained is always short compared with the length available (e.g. in the 'VISA resource name' control, if this counts, or in the 'Slave address' control, which actually is a string) but there doesn't seem to be any huge disadvantage to increasing the width of the box. The height also seems to resize reasonably using the font size property (which conveniently can match the height due to some strangeness discussed elsewhere on these forums regarding font size in pt actually being in pixels, or something).

Did I completely miss the point regarding strings?

[Norbert_B]

I haven't executed your example. I am not seeing any ErrString or ErrButton when viewing the front panel of the Cooler Unit.vi.

Can you explain where to find these?

Fonts do not change when resizing the element. That means that for single line string entry elements, a vertical resize doesn't make sense unless you also change the font size.

And you are correct that string length is often also an issue for resizing. To prevent strings overlaying other elements, you should define a minimum size of the panel.

[cbutcher]

The ErrButton control and ErrString indicators are on top of the panel, and hidden on the copy I uploaded.  The real VI displays these when an error occurs but to see them double clicking the block diagram terminals should show them. Unfortunately the decoration can't be so easily seen but it's only a background box. Hitting Ctrl-A on the front panel should show the outline.

The Resize_String VI changes both the font size and the height properties. I think the order is important but I don't remember which I did first. It, and the other individual resize VIs should be under Private>Handle Controls or similar virtual folders in the project.

Although I don't believe a minimum size is defined in the copy I uploaded I will take care to ensure a sensible minimum in my full code.

[Norbert_B · Accepted solution]

I did copy your example on my disk and started to review the behavior. With following results:

1. VISA resource name label moves incorrectly is solved by using a modern VISA resource element instead of the classic one
2. Removing digital display of the thermometer prevents invalid placing (overlapping) of it. I haven't reviewed your code in that detail that i can tell you why the misplacement takes place
3. All controls are resized incorrectly in all dimensions if resize of the panel is done only in one dimension, e.g. horizontal. Your controls do change in height as well in this example which leads to overlays

Please do NOT use elements of different kind (modern, classic, silver) in a single UI (in your case: multiple VIs)!

[cbutcher]

---

@Norbert_B wrote:

I did copy your example on my disk and started to review the behavior. With following results:

1. VISA resource name label moves incorrectly is solved by using a modern VISA resource element instead of the classic one

---

You're quite right - seems pretty careless of me to have not noticed the mismatch in styles (I know the thermometer is Silver, but I had thought everything else was my default 'Modern' style). Very nice to know that changing the VISA reference to Modern fixes the strange label behaviour.

3. All controls are resized incorrectly in all dimensions if resize of the panel is done only in one dimension, e.g. horizontal. Your controls do change in height as well in this example which leads to overlays

---

I think actually it's that I left a fixed space for the status bar, and when the width becomes large the height exceeds the space, whilst for the rocker button, I only resized based on width in order to have a fixed aspect ratio. Guess I'll have to look into both of these decisions again. The default behaviour for an array of LED indicators with 'Scale all objects on front panel...' is to change their individual shape to fill the appropriate fraction of the window - perhaps I can have another go at working out the needed height and width to make this work - it certainly would be better than the problem you've highlighted (I had seen it, but not identified it as the height changing when I change the width of the window - seems obvious in hindsight).