Allowing user to resize a Front Panel Control

[PrasannaSSRK]

Hello LabVIEW users,

I have a string control in my front panel. During Runtime, I need to allow the user to resize the control by just clicking and dragging its boundaries. I know how to change its size programmatically. But allowing the user to change in FP itself is a bit difficult and I don't find any solutions. Is there any way to achieve this?

[Bob_Schor]

There are several methods that come to mind.  Since you know how (presumably by using Property Nodes) to change the size programmatically, you could have a "Width" and Height" control (perhaps set to allow only "reasonable" values, like 30 to 60 pixels).  You could also have a "Change Size" pushbutton that pops up a Dialog Box that says "Current width = 45, enter percentage change desired from 75% to 150%", and allows 100% for "no change", being dismissed on a Value Changed Event.

Bob Schor

[PrasannaSSRK]

I could have done that. But my requirement is to resize the control just by dragging it and not using any other controls on the FP writing to the size property node.

[Yamaeda]

Use the MouseDown even on the Control, compare mouse position to Control borders, if e.g. in lower right corner (+/- 4 pixels) set a "resizing mode" in which all MouseMove events Changes the Controls size according to the position. Release this mode on MouseUp.

/Y

[wiebe@CARYA · Accepted solution]

If you're lucky, you can get away with putting the control in a pane surrounded by splitters. That could even live in a subpanel, so the sizing is bounded by a rectangle. Set the control to fit the pane, and you're done! No code required (if your lucky).

See attached VI. If the string control is only scalable in one direction, it will be easier and more comprehensive for the user... You'll only need two splitters then, one locked.

BTW. All other methods AFAIK will result in (different levels of) weird user experiences. For instance, you can detect a mouse down event, but the mouse up event will only trigger when the mouse is inside the front panel (so will the mouse down). So sizing, after a mouse down, to the maximum (for the user outside the panel) will result in a sticky drag, as the mouse up is not detected. You'll have to resort to polling, using the mouse API... It's very hard to get it 100% right. Let me know if you think you're there. I'll either show you where it lacks, or I'd be very interested. 

[altenbach]

Resizing a single string control is pointless, because it will either interfere with other controls or the size of the window. If the front panel has sufficient space for the enlarged control, why not make it larger to begin with? 😮

Another option is to have subVI (or pane)  containing only the string control/indicator and have it auto-size to the windows (or pane). Now you can simply resize the window to resize the control.

Can you explain the purpose of resizing? What are you actually trying to achieve with all this? Maybe there is a fundamentally better solution.

[Bob_Schor]

---

@altenbach wrote:

Resizing a single string control is pointless, because it will either interfere with other controls or the size of the window..

---

I (respectfully) disagree a little bit.  In fact, I spent a little effort to create a "Size-to-Specification" VI that would take a String Indicator, a Path Indicator, or a Combo Box Control and auto-size it based on the contents being displayed and some Attributes such as Font Size, Style (Bold, Italic), Font Color, or Background Color.  My initial application was to have a nice Silver Indicator at the top of the Front Panel that would show the Program Name and Version Number (obtained from the Build Spec).  I added the Combo Box in a Dialog Box asking the User to choose from a set of Options.

I use this sparingly, and in specific situations where I have considered the "Size" question, designing the routine so that size isn't a problem, but clarity and visual simplicity are features I want for a good "User Experience".

Bob Schor

[PrasannaSSRK]

Really thanks for the reply. This although partially solved my requirement still, I came to know that resizing can be done without actual coding. Thanks once again.

[wiebe@CARYA]

---

@Bob_Schor wrote:

---

@altenbach wrote:

Resizing a single string control is pointless, because it will either interfere with other controls or the size of the window..

---

I (respectfully) disagree a little bit.  In fact, I spent a little effort to create a "Size-to-Specification" VI that would take a String Indicator, a Path Indicator, or a Combo Box Control and auto-size it based on the contents being displayed and some Attributes such as Font Size, Style (Bold, Italic), Font Color, or Background Color.  My initial application was to have a nice Silver Indicator at the top of the Front Panel that would show the Program Name and Version Number (obtained from the Build Spec).  I added the Combo Box in a Dialog Box asking the User to choose from a set of Options.

I use this sparingly, and in specific situations where I have considered the "Size" question, designing the routine so that size isn't a problem, but clarity and visual simplicity are features I want for a good "User Experience".

Bob Schor

---

I actually have a similar situation, where a non-transparent label of a grouped set of controls overlapped a grouping decoration. Since the label is dynamic, it needs to grow\shrink.

But I agree with Christian that usually a single user scalable control is kinda pointless from a UI design PoV.

[Mancho00]

---

wiebe@CARYA wrote:

... So sizing, after a mouse down, to the maximum (for the user outside the panel) will result in a sticky drag, as the mouse up is not detected. You'll have to resort to polling, using the mouse API.... 

---

Actually, you just need to detect mouse leave for the panel.